Summary: | www-servers/uwsgi-1.4.5 init script race condition if starting multiple uwsgi instances with different UIDs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michele Beltrame <mb> |
Component: | [OLD] Server | Assignee: | Ultrabug <ultrabug> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | mb, python |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Fix for race condition in /etc/init.d/uwsgi |
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 |
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.