Created attachment 338254 [details] Fix for race condition in /etc/init.d/uwsgi Suppose you have two uwgi configurations: ==> app1.conf UWSGI_USER=app1user + other things, of course ==> app2.conf UWSGI_USER=app2user + other things, of course When starting the instances with the symlinked /etc/init.d/uwsgi.app1 and /etc/init.d/uwsgi.app2 the init scripts creates the PID files in: /var/run/uwsgi/app1 /var/run/uwsgi/app2 The problem is that init script "chowns" /var/run/uwsgi/ to the UWSGI_USER of the process, displaying also a warning about that if it wasn't already properly set. As I start a bunch of uwsgi instances with different UIDs at system startup, what I noticed was that the following race condition sometimes happens: app1 init script chowns /var/run/uwsgi/ to app1user, then app2 init script re-chowns it to app2user; in the meanwhile app1 uwsgi server starts but it cannot write the PID file in /var/run/uwsgi/ as it was chowned to the other user, so it aborts and doesn't start at all. I fixed /etc/init.d/uwsgi as per attached patch (bascially it now uses a different directory for each PID): it works, but I don't know if it's the correct way to handle it.
I entered the wrong names of configuration files, sorry. It's understandable, but these are the correct ones: ==> /etc/conf.d/uwsgi.app1 UWSGI_USER=app1user + other things, of course ==> /etc/conf.d/uwsgi.app2 UWSGI_USER=app2user + other things, of course
Hi Michele, You're right indeed, I just added a condition on the SVCNAME so we don't create a uwsgi_uwsgi folder for emperor modes +*uwsgi-1.4.5-r1 (21 Feb 2013) + + 21 Feb 2013; Ultrabug <ultrabug@gentoo.org> +uwsgi-1.4.5-r1.ebuild, + +files/uwsgi.initd-r2: + fix init script for standalone apps, fix #456048 thx to Michele Beltrame + Thank you
