用nginx+uwsgi+python+flask/django部署3个web,使用supervisor监控管理uwsgi进程,2个正常另1个无法启动uwsgi进程

site1,site2和site3使用各自的virtualenv环境运行,site1为django app,site2与site3同为flask app且配置基本相同,最终结果是site1和site2运行正常,site3不正常,检查supervisor日志应该是site3的uwsgi进程起不来,不知道为什么,花了一个晚上了还是找不出问原因,谁有空帮忙看下,感谢

supervisor的日志如下

2013-04-24 22:36:47,316 INFO success: site1 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2013-04-24 22:36:47,316 INFO success: site2 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2013-04-24 22:36:47,317 INFO spawned: 'site3' with pid 14559
2013-04-24 22:36:47,327 INFO exited: site3 (exit status 1; not expected)
2013-04-24 22:36:49,331 INFO spawned: 'site3' with pid 14564
2013-04-24 22:36:49,339 INFO exited: site3 (exit status 1; not expected)
2013-04-24 22:36:52,343 INFO spawned: 'site3' with pid 14566
2013-04-24 22:36:52,351 INFO exited: site3 (exit status 1; not expected)
2013-04-24 22:36:53,352 INFO gave up: site3 entered FATAL state, too many start retries too quickly

site3的uwsgi日志如下

unable to load configuration from 666
unable to load configuration from 666
unable to load configuration from 666
unable to load configuration from 666

site3 nginx配置

server {
    listen 80;
    server_name site3.site2.com;
    access_log /var/log/nginx/site3.site2.com.access.log;
    error_log /var/log/nginx/site3.site2.com.error.log;
    location /
    {
        include uwsgi_params;
        uwsgi_pass unix:///tmp/uwsgi_site3.sock;
    }
    location ~ /\.    { access_log off; log_not_found off; deny all; }
    location ~ ~$     { access_log off; log_not_found off; deny all; }
}

site2 nginx配置

server {
    listen 80;
    server_name site2.com www.site2.com;
    access_log /var/log/nginx/site2.com.access.log;
    error_log /var/log/nginx/site2.com.error.log;
    location /
    {
        include uwsgi_params;
        uwsgi_pass unix:///tmp/uwsgi_site2.sock;
    }
    location ~ /\.    { access_log off; log_not_found off; deny all; }
    location ~ ~$     { access_log off; log_not_found off; deny all; }
}

supervisor配置

[program:site2]
command=/home/user/workspace/venvs/site2/env/bin/uwsgi -s /tmp/uwsgi_site2.sock -w runserver:app -H /home/user/workspace/venvs/site2/env --chmod-socket 666
directory=/home/user/workspace/venvs/site2
autostart=true
autorestart=true
stdout_logfile=/home/user/workspace/venvs/site2/uwsgi.log
redirect_stderr=true
stopsignal=QUIT

[program:site1]
command=/home/user/workspace/venvs/site1/env/bin/uwsgi -s /tmp/uwsgi_site1.sock -w wsgi:application -H /home/user/workspace/venvs/site1/env --chmod-socket 666
directory=/home/user/workspace/venvs/site1
autostart=true
autorestart=true
stdout_logfile=/home/user/workspace/venvs/site1/uwsgi.log
redirect_stderr=true
stopsignal=QUIT

[program:site3]
command=/home/user/workspace/venvs/site3/env/bin/uwsgi -s /tmp/uwsgi_site3.sock -w runserver:app -H /home/user/workspace/venvs/site3/env --chmod-socket 666
directory=/home/user/workspace/venvs/site3
autostart=true
autorestart=true
stdout_logfile=/home/user/workspace/venvs/site3/uwsgi.log
redirect_stderr=true
stopsignal=QUIT

site2 app

from site2 import app
from site2.database import init_db

try:
    init_db()
except:
    pass

if __name__ == '__main__':
    app.run()

site3 app

from site3 import app
from site3.database import init_db, init_testdata, test_db

if __name__ == '__main__':
    init_db()
    init_testdata()
    test_db()
    app.run()
阅读 18.1k
2 个回答

问题我自己解决了,但是具体原因不明,我的服务器的环境是debian 6,web1和web2的virtualenv是以前创建的,web3的virtualenv是最近才创建的,而这段时间间隔内我升级过debian,把老的virtualenv环境拷贝过来用就没问题了,新的不行。

几种情况

  1. 将web1或web2的virtualenv拷贝给web3使用不会有上面问题
  2. 使用新创建的virtualenv会有上面的问题
  3. 直接在virtualenv环境内运行python runserver.py也没有问题

问题原因

问题原因可以再探讨,目前我还没找到,应该出在uwsgi上

谢谢你自问自答的问题。。

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题