Deploy 3 web sites with nginx plus uwsgi plus python plus Flask (web framework)/Django, monitor and manage uwsgi process with supervisor, 2 normal and 1 unable to start uwsgi process

  python

Site1, site2 and site3 run in their respective virtualenv environments. site1 is django app, site2 and site3 are both Flask (web framework) APP and have basically the same configuration. The final result is that site1 and site2 are operating normally and site3 is not normal. The uwsgi process to check the supervisor log should be site3 is unable to get up. I don’t know why, it took all night but I still can’t find out the reason. Who is free to help look at it. Thank you.

The supervisor’s log is as follows

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

The uwsgi log for site3 is as follows

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 configuration

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 /
 bracket
 include uwsgi_params;
 uwsgi_pass unix:///tmp/uwsgi_site3.sock;
 bracket
 location ~ /\.    { access_log off;   log_not_found off;   deny all;  bracket
 location ~ ~$     { access_log off;   log_not_found off;   deny all;  bracket
 bracket

Site2 nginx configuration

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 /
 bracket
 include uwsgi_params;
 uwsgi_pass unix:///tmp/uwsgi_site2.sock;
 bracket
 location ~ /\.    { access_log off;   log_not_found off;   deny all;  bracket
 location ~ ~$     { access_log off;   log_not_found off;   deny all;  bracket
 bracket

Supervisor configuration

[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()

I have solved the problem myself, but the specific reason is not clear. My server environment is debian 6, virtualenv of web1 and web2 was created before, and virtualenv of web3 was created only recently. During this period of time, I upgraded debian and copied the old virtualenv environment to use it. No problem with the new one.

Several situations

  1. Copying virtualenv of web1 or web2 to web3 for use will not have the above problems.
  2. Using the newly created virtualenv will have the above problems.
  3. Run directly in virtualenv environmentpython runserver.pyThere is no problem either.

Cause of problem

The cause of the problem can be discussed again. I haven’t found it yet. It should be in uwsgi.