I'm having some trouble running Emperor mode and I suspect there's a race
condition that's creating this problem. The repro is pretty simple, use the
basic upstart conf file to spin up a uWSGI Emperor with has a vassal who has
vacuum enabled.
I suspect it's the same issue as:
http://lists.unbit.it/pipermail/uwsgi/2012-February/003551.html
Then do 'sudo service uwsgi restart' - the end result (from looking at the logs)
is that the vassal restarts and after it restarts, the socket file is vacuumed.
What I think is happening is something like this:
upstart tells the emperor to shut down
emperor shuts down (doesn't notify anyone)
vassal loses connection with emperor, starts killing workers
upstart notes that the emperor is shut down
upstart starts new-emperor
new-emperor reads ini files and starts new-vassal
new-vassal starts checks for socketfile - it exists, proceeds to 'ready'
vassal finishes shutting down - triggers vacuum
End result is that the socket file is gone and uwsgi thinks that everything is
fine.
Here's the log excerpt:
Fri Jun 8 01:35:17 2012 - ...brutally killing workers...
Fri Jun 8 01:35:17 2012 - lost connection with my emperor !!!
Fri Jun 8 01:35:17 2012 - SIGINT/SIGQUIT received...killing workers...
Fri Jun 8 01:35:18 2012 - *** Starting uWSGI 1.2.3 (64bit) on [Fri Jun 8
01:35:18 2012] ***
Fri Jun 8 01:35:18 2012 - compiled with version: 4.6.3 on 08 June 2012 00:22:34
Fri Jun 8 01:35:18 2012 - detected number of CPU cores: 4
Fri Jun 8 01:35:18 2012 - current working directory: /etc/uwsgi/apps-enabled
Fri Jun 8 01:35:18 2012 - detected binary path: /usr/local/bin/uwsgi
Fri Jun 8 01:35:18 2012 - setgid() to 33
Fri Jun 8 01:35:18 2012 - setuid() to 1009
Fri Jun 8 01:35:18 2012 - your memory page size is 4096 bytes
Fri Jun 8 01:35:18 2012 - detected max file descriptor number: 1024
Fri Jun 8 01:35:18 2012 - lock engine: pthread robust mutexes
Fri Jun 8 01:35:18 2012 - uwsgi socket 0 bound to UNIX address
/tmp/uwsgi.site.sock fd 3
Fri Jun 8 01:35:18 2012 - Python version: 2.7.3 (default, Apr 20 2012,
23:04:22) [GCC 4.6.3]
Fri Jun 8 01:35:18 2012 - Set PythonHome to /foo/
Fri Jun 8 01:35:18 2012 - *** Python threads support is disabled. You can
enable it with --enable-threads ***
Fri Jun 8 01:35:18 2012 - Python main interpreter initialized at 0x19d3560
Fri Jun 8 01:35:18 2012 - your server socket listen backlog is limited to 100
connections
Fri Jun 8 01:35:18 2012 - *** Operational MODE: single process ***
Fri Jun 8 01:35:18 2012 - added /foo/src/ to pythonpath.
Fri Jun 8 01:35:18 2012 - WSGI app 0 (mountpoint='') ready in 0 seconds on
interpreter 0x19d3560 pid: 28434 (default app)
Fri Jun 8 01:35:18 2012 - *** uWSGI is running in multiple interpreter mode ***
Fri Jun 8 01:35:18 2012 - spawned uWSGI master process (pid: 28434)
Fri Jun 8 01:35:18 2012 - spawned uWSGI worker 1 (pid: 28435, cores: 1)
Fri Jun 8 01:35:19 2012 - VACUUM: unix socket /tmp/uwsgi.site.sock removed.
The reason I suspect this is indeed the race condition that doing a 'sudo
service uwsgi stop' works fine to shut it down, but there's about a second or
two delay before the 'vacuum' line appears in the log.
I'm happy to provide my config files if needed.
Is there a way to tell the Emperor to wait for the vassals to shut down before
shutting down itself? I'd prefer to avoid introducing a delay into the 'stop'.
--
--Leo
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
