Reloading through SIGHUP kills uwsgi, unable to chown socket

[AMDmi3]

uwsgi running like this:

/usr/local/bin/uwsgi -M --manage-script-name --mount /=repology-app:app --pythonpath=/var/db/repology/repology --pidfile /var/run/uwsgi-repology.pid -s /var/run/repology/uwsgi.socket --chmod-socket=660 --chown-socket=www:www -d /var/log/uwsgi-repology.log --uid repology --gid repology

The config is pretty common - application is running under its own dedicated user repology, and socket is owned by www as it should be accessed by frontend (nginx running as www).

when issuing SIGHUP, it dies with

chown(): Operation not permitted [core/utils.c line 2623]

in the log, likely because it's already running as repology and is thus unable to change socket ownership to www.

• Likely it should check socket permissions and don't try to change them if they are already correct.
• Definitely it should not die from SIGHUP, like all well-behaving servers. Such errors should not be considered fatal.

[ghost]

I'm seeing this as well. With the defaults on FreeBSD now uwsgi is started by root, creates the socket as www:www, and drops privileges to uwsgi user. This gives us nice isolation, but a SIGHUP causes it to close the unix and network sockets and attempt to re-open them. It fails because it no longer has root privileges so it can't recreate a socket owned by www:www, then terminates.

I don't understand why a reload requires destroying the sockets...

[xrmx]

@AMDmi3 @feld what version of uwsgi is this?

[AMDmi3]

2.0.14

[ghost]

Any updates on this?

[AMDmi3]

Note that above mentioned FreeBSD ports commits didn't fix this.

[DuncanFairley]

The socket permissions were screwed for me upon updating to 2.0.15 from 2.0.13 on FreeBSD.

[theory14]

I have the same problem when I moved to 2.0.15 on FreeBSD 11.1 RELEASE. I solved this just now by setting uwsgi to run as www and the socket owner to www:
uwsgi_uid="www"
uwsgi_gid="www"
uwsgi_socket_owner="www"

The socket is then owned by www and the SIGHUP reload works as expected.

Setting those to default UID to uwsgi and socket_owner to uwsgi results in failure. The socket is owned by uwsgi and the uwsgi processes are running as uwsgi.

Something just doesn't make sense here... Why does one unprivileged user work and another doesn't?

[tehfink]

This is to note that @theory14's solution did not work for me on FreeBSD 11.1 in a jail with uwsgi-py36-2.0.15_3…

[mozumder]

I've faced this issue for over a year on FreeBSD. I still don't have a solution to this. I have to kill -9 the emperor processes to stop UWSGI.

[AMDmi3]

I have to kill -9 the emperor processes to stop UWSGI

service uwsgi restart should be quite enough (however not service uwsgi reload which is broken because of the mentioned problem).

[citrin]

I have the same problem with uwsgi 2.0.17.1 on FreeBSD 11.2 - for some reason Unix socket is not inherited after reload (SIGHUP).
Log look like:

uwsgi_setup_inherited_sockets() is called (debug log added by me)
error removing unix socket, unlink(): Permission denied [core/socket.c line 198]                                                                                                                                                              
bind(): Address already in use [core/socket.c line 230]

[citrin]

As I can see problem is in function uwsgi_add_socket_from_fd(). Adding memset(&usa, 0, sizeof(usa)); fixes problem for me, but may be other changes to uwsgi_add_socket_from_fd() is required.

[karolyi]

I can still reproduce the problem with using the latest dev, 2.1-dev-f17bdbd1.

[karolyi]

Also with 2.0.18.

[karolyi]

It seems that the two offending lines in /usr/local/etc/rc.d/uwsgi are:

               rc_flags=${rc_flags}" --vassals-set uid=${uwsgi_uid} --vassals-set gid=${uwsgi_gid}"
               rc_flags=${rc_flags}" --vassals-set chmod-socket=${uwsgi_socket_mode} --vassals-set chown-socket=${uwsgi_socket_owner}"

Line 130-131. Commenting these two lines out will help uwsgi start/reload normally. I use the emperor-tyrant option, and with that the passed parameters to uwsgi vassals above are not only meaningless/harmful, they hinder startup.