Hi,

on my uwsgi-emperor setup, I've noticed that uwsgi-emperor fails to
stop or restart. e.g. when running `systemctl stop uwsgi-emperor`, I get
(in `systemctl status uwsgi-emperor`):

  systemd[1]: Stopping LSB: Start/stop uWSGI server instance(s)...
  uwsgi-emperor[11470]: start-stop-daemon: matching on world-writable pidfile /run/uwsgi-emperor.pid is insecure
  systemd[1]: uwsgi-emperor.service: Succeeded.

However, even though this says "Succeeded", uwsgi-emperor is still
running as before, so I suspect start-stop-daemon has refused to act.

Looking at the pidfile, I see indeed 666 permissions:

  -rw-rw-rw- 1 root root 6 aug 14 07:51 /run/uwsgi-emperor.pid

Manually clearing the permissions (`chmod o-rwx /run/uwsgi-emperor.pid`)
before running stopping indeed fixes both the message and makes the
emperor stop properly.

I found a mailing list post which suggests that
this is due to the --daemonize option, which sets the umask to 0:

http://lists.unbit.it/pipermail/uwsgi/2013-April/005803.html

I think this issue has started occurring after upgrading to Buster. I
suspect that maybe start-stop-daemon has become more strict in its
permission check, or maybe the permissions changed on the uwsgi side.

Adding `--umask 022` to the initscript fixed the permissions for my
setup, but I suspect this might actually change all kinds of permissions
for other files too, so this might not be ideal as a general solution.

It seems uwsgi does not currently have any option to set the permissions
of the pidfile, which might be the best solution. Doing a chmod from the
init script seems like a workaround, but AFAICS would leave a race
condition where the pidfile is writable for a short while.

I have only tested this on a configured production system, but I highly
suspect that this is not related to my setup, but also broken in a
default installation. I've included my emperor config below as an
indication.

Gr.

Matthijs

Exact same problem here, on bullseye/sid with uwsgi version 2.0.18-debian.
Confirmed on 2 systems with the same configuration.

I've just hit the same issue - I was wondering why I couldn't shut down
or restart the service!

In looking at how to fix it I see that /lib/init/init-d-script will call
a do_start_prepare function if defined, so I've edited
/etc/init.d/uwsgi-emperor to add this towards the end to pre-create the
pidfile (as uwsgi will just write to it if it exists):

do_start_prepare() {
         # Create with correct permissions in advance as uwsgi with
--daemonize creates it world write otherwise
         touch "$PIDFILE"
}

That seems to do the job (dunno if it's worth/problematic to set umask
explicitly in the init.d script as well to ensure that pidfile is
correctly created).

Same issue here, systemctl start/stop/restart ineffective.

Debian 10 / buster

Package: uwsgi-emperor
Source: uwsgi
Version: 2.0.18-1
Installed-Size: 65
Maintainer: uWSGI packaging team <pkg-uwsgi-devel@lists.alioth.debian.org>
Architecture: amd64
Depends: uwsgi-core (= 2.0.18-1)

We believe that the bug you reported is fixed in the latest version of
uwsgi, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 934731@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Alexandre Rossi <niol@zincube.net> (supplier of updated uwsgi package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 22 Feb 2026 18:17:03 +0100
Source: uwsgi
Architecture: source
Version: 2.0.31-3
Distribution: unstable
Urgency: medium
Maintainer: uWSGI packaging team <pkg-uwsgi-devel@lists.alioth.debian.org>
Changed-By: Alexandre Rossi <niol@zincube.net>
Closes: 934731 1128380
Changes:
 uwsgi (2.0.31-3) unstable; urgency=medium
 .
   * -dbgsym migration now done
   * uwsgi-extra is Multi-Arch foreign
   * autopkgtest: fix test_mountpoints not run
   * fix pidfile default permissions (Closes: #934731, #1128380)
Checksums-Sha1:
 72d2b3e87661d21a795d8c603e580ab14c4d7d11 3453 uwsgi_2.0.31-3.dsc
 2ab3d3757c9a0a8cdcc6fd176f9fc9de82179488 57316 uwsgi_2.0.31-3.debian.tar.xz
 c0fcbcff4b2fe46499f90f8fa2b716e94b131b75 17396 uwsgi_2.0.31-3_amd64.buildinfo
Checksums-Sha256:
 ea7b019ae9adebcfb6217bfb97d93fe1f035d15f05a61f58a716db22e76c32fc 3453 uwsgi_2.0.31-3.dsc
 c5fe6cd3d6264e715e1c8578d8491106a89e924f87b7edbca13a01e72cf69f48 57316 uwsgi_2.0.31-3.debian.tar.xz
 9197f492b1feb8246911d38dce38cc9a33d75a0e8572a1da004339b0e7c39ecd 17396 uwsgi_2.0.31-3_amd64.buildinfo
Files:
 28e733246cdee56097c0dd2a0f982ee4 3453 httpd optional uwsgi_2.0.31-3.dsc
 67782ede4e7b92efddbc29657af79d55 57316 httpd optional uwsgi_2.0.31-3.debian.tar.xz
 2728e5901e4d8f0addff140080b23e01 17396 httpd optional uwsgi_2.0.31-3_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmmrNaYWHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICO/gD/9aDBJydVT4gPRdLAP+4lnfbskr
oEyILWUlrcMxr+6GKDcX9ym0CYh+AGLkcqcQ6RatTJw33iXmy80iahT5IUjSXrVf
592qGcR9lHByURQOGeJQvA/QP3clV5f6XP3tdp0WiXkwSO328ypIKrCMC/rrmvz7
kCa8yBfE9U6Juki0ZvYo3ct2JJsbGFhUnMsssjN5mdcOjBYv8Z4mUWmBg3sFJHrK
Potr9EbloxROdQH2m6hpy7Iop13mxXx2oT+p9QYakDyhpHZn1hIMIbtGIQ4NpnSj
DCIERyLuo9IwWw422syd73a16v84ozysZll6xttM4BML233yH9764pAqZbHK7hwe
vwo1h/obADkwTriBahjY1TG8F5tSXdk3w/TKIN1bDTw4sG1CulVob3o9d9rzd8ma
IC9tkR8mf1tFLvqwkr6+Uh4AfGij9XP0Alu0eX8MJf7c8U9oII42WfuBovaTNXn4
MK881OGx/fxT5we3j4ncdYuaVc/8E+OFI+R1pUVmjv+BOF/HN/kXFvvlvP7aaMrc
n2wOm5rfQWvDeumZCXlRtwJgG5ZZXGYhUj1p8c3ynlBoUfzyvBLpcwxye6vjTlwE
UVzduvPz1DpVjwRn8zbhS04Etn4lpEKqW2rqayZpmul2JbrfgAeuVOko7iRz8e5t
mmo5yLRVs+2d1UP7LQ==
=Z5xe
-----END PGP SIGNATURE-----