uWSGI作为进程工作，但不作为守护进程 [英] uWSGI works as process but not as daemon

查看：211
本文介绍了uWSGI作为进程工作，但不作为守护进程的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

对于我目前的烧瓶部署，我不得不建立一个uwsgi服务器。
这就是我创建uwsgi守护进程的方式：
$ b $ sudo vim /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 / 
  
 
  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 
 $ b $ app_template_filter（'format_date'）
 def format_date（value）：
 day =格式（day.upper（），affix（value.day））
  babel_dates.format_date（value，EE）
返回{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 as www-data and hence can not access the /var/log/uwsgi/error.log since the error.log was owned by root: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 as www-data.  And also don't forget to make the whole project accessible to www-data or the daemon will fail with an Internal 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 by root instead of www-data. In that case simply delete the sock file sudo rm /tmp/uwsgi.sock
    • 

  • tail -f /myproject/error.log  --> Shows errors thrown by uwsgi in your application
    • 




This 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屋！
查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆