Comment 6 for bug 1131314

Revision history for this message
Paul Kilgo (paulkilgo) wrote :

I had this same problem too. I wonder if this is actually a mixture of a confusing init script message mixed with the quirks about how uwsgi decided to respond to signals.

This tipped me off:

http://serverfault.com/questions/347819/ubuntu-11-10-with-nginx-and-uwsgi

So uwsgi has two pidfile options "pidfile" and "pidfile2" which each create the pidfile before and after the privilege drop respectively according to the documentation. By default, Ubuntu 14.04 seems to use /run/uwsgi/app/myapp/pid as the default pid file.

See the documentation linked in that QA thread:

http://uwsgi-docs.readthedocs.org/en/latest/Options.html#pidfile2

I modified my init script to print out the path of the pid file it tries to use to stop the processes. Here is the results I am seeing when testing setting "pidfile" and "pidfile2" to "/run/buffet.pid". See the attached log.

So what I gather is:

1. Setting "pidfile" actually overrides the pidfile the init scripts create (though its permission mode looks dubious)
2. Setting "pidfile2" means both pidfiles will get created
3. "service uwsgi stop" doesn't care about what setting you used. It always uses the default. That's why it can't kill the processes if you have manually configured a custom path to a pid file.

I wonder if item #1 poses a security issue in the case that a sysadmin tries to write their own script to kill uwsgi processes based on the configured path to the pid file.

Now, for the uwsgi processes not responding to SIGTERM, this is actually documented behavior. It is the second item in:

http://uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html

Basically it says that uwsgi processes will not terminate on SIGTERM, and you should instead send them SIGQUIT. This seems to work (killall -s SIGQUIT uwsgi).

I am still baffled about "service uwsgi status" simply saying "which one?"; I really think it ought to check the status of all enabled apps if that is at all possible, or at least print a usage message. "service uwsgi status myapp" seems to work as expected.