用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()
python flask nginx uwsgi supervisor
无聊的水水
10 years, 10 months ago
Answers
问题我自己解决了,但是具体原因不明,我的服务器的环境是debian 6,web1和web2的virtualenv是以前创建的,web3的virtualenv是最近才创建的,而这段时间间隔内我升级过debian,把老的virtualenv环境拷贝过来用就没问题了,新的不行。
几种情况
- 将web1或web2的virtualenv拷贝给web3使用不会有上面问题
- 使用新创建的virtualenv会有上面的问题
-
直接在virtualenv环境内运行
python runserver.py
也没有问题
问题原因
问题原因可以再探讨,目前我还没找到,应该出在uwsgi上
弄爆你的菊
answered 10 years, 10 months ago