Your message dated Fri, 06 Mar 2026 20:44:58 +0000
with message-id <[email protected]>
and subject line Bug#934731: fixed in uwsgi 2.0.31-3
has caused the Debian Bug report #934731,
regarding uwsgi-emperor: Fails to stop due to too wide pidfile permissions
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
934731: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934731
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: uwsgi-emperor
Version: 2.0.18-1
Severity: normal
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
-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (990, 'stable'), (800, 'testing'), (700, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages uwsgi-emperor depends on:
ii uwsgi-core 2.0.18-1
uwsgi-emperor recommends no packages.
uwsgi-emperor suggests no packages.
-- Configuration Files:
/etc/uwsgi-emperor/emperor.ini changed:
[uwsgi]
log-date = true
strict = true
set-placeholder = base-dir=/etc/uwsgi-emperor
emperor = glob://%(base-dir)/vassals/*/app-*.ini
emperor = glob://%(base-dir)/vassals/app-*.ini
vassals-include-before = vassal-defaults.ini
hook-as-vassal = callret:chdir %(base-dir)
show-config = 1
-- no debconf information
--- End Message ---
--- Begin Message ---
Source: uwsgi
Source-Version: 2.0.31-3
Done: Alexandre Rossi <[email protected]>
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 [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Alexandre Rossi <[email protected]> (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 [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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 <[email protected]>
Changed-By: Alexandre Rossi <[email protected]>
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-----
pgpXf0Gycub6R.pgp
Description: PGP signature
--- End Message ---
