Bug 216924 - www/uwsgi: can't reload\start\stop
Summary: www/uwsgi: can't reload\start\stop
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
: 217178 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-02-08 19:21 UTC by robert.ayrapetyan
Modified: 2020-08-21 15:00 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (demon)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description robert.ayrapetyan 2017-02-08 19:21:55 UTC
After latest updates (I guess two latest security patches) uwsgi daemon can not be reloaded anymore with www user:

sudo -u www uwsgi --reload /var/run/uwsgi.pid
signal_pidfile()/kill(): Operation not permitted [core/uwsgi.c line 1656]

rc.conf settings:
uwsgi_enable="YES"
uwsgi_flags="--master --emperor /usr/local/etc/uwsgi/vassals --die-on-term"
uwsgi_logfile="/var/log/uwsgi/uwsgi.log"

"sudo service uwsgi stop" also doesn't work, it hangs forever:
sudo service uwsgi stop
Stopping uwsgi.
Waiting for PIDS: 43969

Logs:
waiting for Emperor death...
waiting for Emperor death...
waiting for Emperor death...

The only thing which work:
sudo pkill -9 uwsgi
sudo service uwsgi start
Comment 1 Mark Felder freebsd_committer freebsd_triage 2017-02-08 20:35:34 UTC
Let me see if I can reproduce this... thanks for the report.
Comment 2 robert.ayrapetyan 2017-03-01 07:32:38 UTC
Any update on that? Thanks!
Comment 3 Mark Felder freebsd_committer freebsd_triage 2017-03-01 13:36:11 UTC
(In reply to robert.ayrapetyan from comment #0)

I can start/stop/restart just fine, but it appears it doesn't reload nicely. As found in the logs:

error removing unix socket, unlink(): Operation not permitted [core/socket.c line 198]
bind(): Address already in use [core/socket.c line 230]

This appears to be a bug in uwsgi related to the socket owner being different than the daemon user. At start it handles this all as root then drops privs, but cannot handle "reload" as it no longer has the privs. Although I'm not sure why uwsgi needs to wipe out its unix and network sockets to reload...
Comment 4 Mark Felder freebsd_committer freebsd_triage 2017-03-01 13:40:40 UTC
There is an open github issue for this:

https://github.com/unbit/uwsgi/issues/1471
Comment 5 Mark Felder freebsd_committer freebsd_triage 2017-04-25 16:16:13 UTC
This has not been forgotten. I've left a new comment on the github bug.
Comment 6 VK freebsd_triage 2017-12-13 13:33:14 UTC
*** Bug 217178 has been marked as a duplicate of this bug. ***
Comment 7 VK freebsd_triage 2017-12-13 13:36:14 UTC
BTW, the workaround is to create, say, `/var/run/uwsgi` and chown it to the running user, and then set `uwsgi_pidfile` into that directory.

This is especially so if you want to run jails without any root processes.
Comment 8 teh_fink 2018-02-15 14:48:12 UTC
Can still confirm uwsgi hanging forever using "sudo service uwsgi stop" with uwsgi-py36-2.0.15_3 on FreeBSD 11.1 in a jail, with only `uwsgi_enable="YES"` in rc.conf.
Comment 9 teh_fink 2018-02-15 15:05:17 UTC
(In reply to Vladimir Krstulja from comment #7)
Thanks for this, but unfortunately it didn't make a difference in my case. I still receive the hanging "waiting for Emperor death..."