Issuing "service uwsgi reload" creates zombie uwsgi processes

I have the same problem - uwsgi decided to be zombified, and when I mistakenly decided to reboot the VPS, it got stuck because uwsgi was still zombified.

Status changed to 'Confirmed' because the bug affects multiple users.

Managing uwsgi daemon with upstart would solve this problem in a more reliable way, right?

I have to add that even when never using reload, stop also doesn't work all the time. When letting uwsgi run for a while I thought I'd be safe not using reload, but stop and start. But after stop there are still processes running.

service uwsgi start
(let some time pass)
service uwsgi stop

Expected result: No uwsgi processes running.

Actual result: several uwsgi-core processes remain running and can only be stopped with SIGKILL.

This is on 12.04.2 LTS.

Same problem. I have never used "service uwsgi reload", but now I have 8 zombie uwsgi-core processes after "service uwsgi stop".
Debian 6.0.5.

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.

I believe this may be because the init scripts kill using the name 'uwsgi', except when the following variable in /etc/init.d/uwsgi is:

DAEMON="/usr/bin/uwsgi-core" (or in my case: uwsgi_python3)

then the processes are not killed during restart (or stop).

I solved this for uwsgi python by renaming DAEMON to "/usr/bin/uwsgi", and pointing "/usr/bin/uwsgi" to "/etc/alternatives/uwsgi_python3".

I am having the same problem. The workaround described by Jon Walsh did not work for me.