uWSGI作为进程工作,但不作为守护进程 [英] uWSGI works as process but not as daemon
问题描述
这就是我创建uwsgi守护进程的方式:
$ b $ sudo vim /etc/init/uwsgi.conf$c$ /etc/init/uwsgi.conf
描述uWSGI服务器
#file:
启动运行级别[2345]
运行级别停止[!2345]
respawn
exec / myproject / myproject-env / bin / uwsgi --uid www- data --gid www-data --home / myproject / myproject-env / site / F11 / Engineering / --socket /tmp/uwsgi.sock --chmod-socket --module F11 --callable app --pythonpath / myproject / myproject-env / site / F11 / Engineering / -H / myproject / myproject-env
然而,成功运行: sudo start uwsgi
uwsgi start / running,process 1286
尝试通过浏览器访问应用程序:
我得到一个 502 Bad Gateway
和nginx error.log中的错误条目:
2013/06/13 23:47:28 [error ] 743#0:* 296上游提前关闭
连接,同时从上游读取响应头,客户端:
xx.161.xx.228,server:myproject.com,request:GET / show_records / 2013 / 6 HTTP / 1.1,上游:
uwsgi:// unix:///tmp/uwsgi.sock:,主机:myproject.com
但是sock文件具有它所需要的权限:
$ $ $ $ $ $ $ $ $ $ $ $ $ $ srw-rw-rw - 1 www-data www-data 0 Jun 13 23:46 /tmp/uwsgi.sock
如果我从命令行上面运行 exec
命令作为一个进程,它工作得很好。为什么这个守护进程不能正常工作?请问,
btw Nginx运行的是
vim /etc/nginx/nginx.conf
user www-data;
和 vim / etc / nginx / sites-available / default $
location / {
uwsgi_pass unix:///tmp/uwsgi.sock;
包含uwsgi_params;
开始为
sudo service nginx start
我正在
Ubuntu 12.04 LTS
上运行。 b
我希望我已经提供了所有必要的数据,希望有人能指引我进入正确的方向。感谢。解决方案最后我在工作了近2天后解决了这个问题。我希望这个解决方案能够帮助其他正在遇到类似问题的flask / uwsgi用户。
我有两个主要问题导致了这个问题。
1)用守护进程查找问题的最好方法显然是一个日志文件和一个更干净的结构。
$ p code $> sudo vim /etc/init/uwsgi.conf
将守护程序脚本更改为以下内容:
#file:/etc/init/uwsgi.conf
描述uWSGI服务器
运行级别开始[2345]
stop on runlevel [!2345]
respawn
exec /home/ubuntu/uwsgi-1.9.12/uwsgi -c /myproject/uwsgi.ini
vim /myproject/uwsgi.ini
[uwsgi]
socket = /tmp/uwsgi.sock
master = true
enable-threads = true
processes = 5
chdir = / myproject / F11 / Engineering
module = F11:app
virtualenv = / myproject / myproject-env /
uid = www-data
gid = www -data
logto = / myproject / er ror.log
这是设置守护进程的更简洁的方法。另外注意最后一行如何设置日志文件。最初我把日志文件设置为
/var/log/uwsgi/error.log
。经过大量的汗水和泪水,我意识到守护进程正在以www-data
运行,因此无法访问/ var / log / uwsgi / error .log
,因为error.log属于root:root
。这使uwsgi默默地失败。
我发现将日志文件指向我自己的
/ myproject
效率更高,守护进程保证访问为www-data
。另外,不要忘记让整个项目可以被www-data
访问,否则守护进程将会失败,并且出现内部服务器错误信息
。 - >sudo chown www-data:www-data -R / myproject /
$ c $重新启动uwsgi守护程序:
sudo服务 uwsgi restart
2)现在您有三个日志文件可供您查看:
tail -f /var/log/upstart/uwsgi.log
- >显示问题你的守护进程开始
tail -f /var/log/nginx/error.log
- >当wsgi访问被拒绝时显示权限问题,通常是因为/tmp/uwsgi.sock
文件归属于root
www-data
。在这种情况下,只需删除sock文件sudo rm /tmp/uwsgi.sock
tail -f /myproject/error.log
- >显示uwsgi在应用程序中抛出的错误
这个日志文件的组合帮助我弄清楚,在Flask应用程序中,我也有一个Flask-Babel导入的错误。在这个意义上,糟糕的是,我使用库的方式是回落到系统的语言环境来确定日期时间格式。
文件/myproject/F11/Engineering/f11_app/templates/show_records.html,第25行,在块body中
< td> {{record.record_date | format_date}}< / td>
文件./f11_app/filters.py,第7行,在format_date
day = babel_dates.format_date(value,EE)
文件/ myproject / myproject-env / local /lib/python2.7/site-packages/babel/dates.py,第459行,在format_date
返回pattern.apply(date,locale)
文件/ myproject / myproject-env / local /lib/python2.7/site-packages/babel/dates.py,第702行,申请
返回self%DateTimeFormat(datetime,locale)
文件/ myproject / myproject-env / local /lib/python2.7/site-packages/babel/dates.py,第699行,在__mod__
中返回self.format%other
文件/ myproject / myproject-env / local / lib / / myproject / myproject-env / local / lib / python2.7 / site-packages / babel / dates.py python2.7 / site-packages / babel / dates.py,第821行,在format_weekday
返回get_day_names(width,context,self.locale)[weekday]
文件/ myproject / myproject-env /local/lib/python2.7/site-packages/bab el / dates.py,第69行,在get_day_names
返回Locale.parse(locale).days [context] [width]
AttributeError:'NoneType'对象没有属性'days'
这是我使用Flask过滤器的方式:
import babel.dates as babel_dates
babel_dates.format_date(value,EE)
$ b $ app_template_filter('format_date')
def format_date(value):
day =格式(day.upper(),affix(value.day))
返回{0} {1}最奇怪的部分是这个代码在开发环境(!)内工作得很好。从命令行运行uwsgi作为根进程时,它工作的很好。但是在由www-data守护进程运行时会失败。这与Flask-Babel正试图回退的区域设置有关。
当我像这样改变导入时,它一切正常最后用守护进程:
from flask.ext.babel import format_date
@ app.template_filter( 'format_date1')
def format_date1(value):
day = format_date(value,EE)
返回{0} {1}。因此,在使用Eclipse / Aptana Studio的时候要小心,因为它会试图挑选一个或者多个字符串代码中的类的正确命名空间。它可以变成丑陋的。
自从2天以来,它在Amazon Ec2(Ubuntu 12.04)上作为uwsgi守护进程工作得非常好。我希望这个经验可以帮助Python开发者。
For my current flask deployment, I had to set up a uwsgi server. This is how I have created the uwsgi daemon:
sudo vim /etc/init/uwsgi.conf
# file: /etc/init/uwsgi.conf description "uWSGI server" start on runlevel [2345] stop on runlevel [!2345] respawn exec /myproject/myproject-env/bin/uwsgi --uid www-data --gid www-data --home /myproject/myproject-env/site/F11/Engineering/ --socket /tmp/uwsgi.sock --chmod-socket --module F11 --callable app --pythonpath /myproject/myproject-env/site/F11/Engineering/ -H /myproject/myproject-env
However after running this successfully:
sudo start uwsgi
uwsgi start/running, process 1286
And trying to access the application via browser:
I get a 502 Bad Gateway
and an error entry in nginx error.log:
2013/06/13 23:47:28 [error] 743#0: *296 upstream prematurely closed connection while reading response header from upstream, client: xx.161.xx.228, server: myproject.com, request: "GET /show_records/2013/6 HTTP/1.1", upstream: "uwsgi://unix:///tmp/uwsgi.sock:", host: "myproject.com"
But the sock file has the permission it needs:
srw-rw-rw- 1 www-data www-data 0 Jun 13 23:46 /tmp/uwsgi.sock
If I run the
exec
command from above in the command line as a process, it works perfectly fine. Why is the daemon not working correctly please?btw Nginx is running as
vim /etc/nginx/nginx.conf
user www-data;
and
vim /etc/nginx/sites-available/default
location / { uwsgi_pass unix:///tmp/uwsgi.sock; include uwsgi_params; }
and it is started as
sudo service nginx start
I am running this on
Ubuntu 12.04 LTS
.I hope I have provided all the necessary data, hope someone can guide me into the right direction. Thanks.
解决方案Finally I have solved this problem after working nearly 2 days on it. I hope this solution will help other flask/uwsgi users that are experiencing a similar problem.
I had two major issues that caused this.
1) The best way to find the problems with a daemon is obviously a log file and a cleaner structure.
sudo vim /etc/init/uwsgi.conf
Change the daemon script to the following:
# file: /etc/init/uwsgi.conf description "uWSGI server" start on runlevel [2345] stop on runlevel [!2345] respawn exec /home/ubuntu/uwsgi-1.9.12/uwsgi -c /myproject/uwsgi.ini
vim /myproject/uwsgi.ini
[uwsgi] socket = /tmp/uwsgi.sock master = true enable-threads = true processes = 5 chdir= /myproject/F11/Engineering module=F11:app virtualenv = /myproject/myproject-env/ uid = www-data gid = www-data logto = /myproject/error.log
This is much cleaner way of setting up the daemon. Also notice the last line how to setup the log file. Initially I had set the log file to
/var/log/uwsgi/error.log
. After a lot of sweat and tears I realized the daemon is running aswww-data
and hence can not access the/var/log/uwsgi/error.log
since the error.log was owned byroot:root
. This made the uwsgi fail silently.I found it much more efficient to just point the log file to my own
/myproject
, where the daemon has guaranteed access aswww-data
. And also don't forget to make the whole project accessible towww-data
or the daemon will fail with anInternal Server error message
. -->sudo chown www-data:www-data -R /myproject/
Restart uwsgi daemon:
sudo service uwsgi restart
2) Now you have three log files to lookout for:
tail -f /var/log/upstart/uwsgi.log
--> Shows problems with your daemon upon start
tail -f /var/log/nginx/error.log
--> Shows permission problems when wsgi access is refused, often because/tmp/uwsgi.sock
file is owned byroot
instead ofwww-data
. In that case simply delete the sock filesudo rm /tmp/uwsgi.sock
tail -f /myproject/error.log
--> Shows errors thrown by uwsgi in your applicationThis combination of log files helped me to figure out that I also had a bad import with Flask-Babel in my Flask application. Bad in that sense, that the way I utilized the library was falling back to the system's locale to determine the datetime format.
File "/myproject/F11/Engineering/f11_app/templates/show_records.html", line 25, in block "body" <td>{{ record.record_date|format_date }}</td> File "./f11_app/filters.py", line 7, in format_date day = babel_dates.format_date(value, "EE") File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 459, in format_date return pattern.apply(date, locale) File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 702, in apply return self % DateTimeFormat(datetime, locale) File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 699, in __mod__ return self.format % other File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 734, in __getitem__ return self.format_weekday(char, num) File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 821, in format_weekday return get_day_names(width, context, self.locale)[weekday] File "/myproject/myproject-env/local/lib/python2.7/site-packages/babel/dates.py", line 69, in get_day_names return Locale.parse(locale).days[context][width] AttributeError: 'NoneType' object has no attribute 'days'
This is the way I was using the Flask filter:
import babel.dates as babel_dates @app.template_filter('format_date') def format_date(value): day = babel_dates.format_date(value, "EE") return '{0} {1}'.format(day.upper(), affix(value.day))
The strangest part is that this code is working perfectly fine within the dev environment (!). It works even fine when running the uwsgi as a root process from the command line. But it fails when ran by the www-data daemon. This must have something to do with how the locale is set, which Flask-Babel is trying to fall back to.
When I changed the import like this, it all worked finally with the daemon:
from flask.ext.babel import format_date @app.template_filter('format_date1') def format_date1(value): day = format_date(value, "EE") return '{0} {1}'.format(day.upper(), affix(value.day))
Hence be careful when using Eclipse/Aptana Studio that is trying to pick the right namespace for your classes in code. It can really turn ugly.
It is now working perfectly fine as a uwsgi daemon on an Amazon Ec2 (Ubuntu 12.04) since 2 days. I hope this experience helps fellow python developers.
这篇关于uWSGI作为进程工作,但不作为守护进程的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!