Dear Maintainer,

uwsgi is still using an System V service script. After ugprading to systemd 260~rc2-1 on Forky, uwsgi became unusable as no systemd unit file
is provided [1]

# systemctl start uwsgi
Failed to start uwsgi.service: Unit uwsgi.service not found.

/etc/init.d/uwsgi should be replaced by a proper unit files

Regards

[1] Systemd changelog : https://sources.debian.org/src/systemd/260~rc2-1/NEWS

It appears that the systemd integration uses uwsgi-app@.service, and
not uwsgi.service.

Maybe there needs to be an upgrade path.

Chris

Hi,

Is /usr/share/doc/uwsgi-core/README.Debian not enough?

    # systemctl enable uwsgi-app@r<confname>.service

If not, please describe your use case so we can improve the documentation
or the systemd (template) units.

Thanks,

Alex

This service file is meant to be used alongisde the uwsgi-app@.socket
(no [Install] section in the service file)
Well, the first part /usr/share/doc/uwsgi-core/README.Debian can be
dropped :)

The rest seems to be a incomplete copy of uWSGI doc [1]. The missing
part being the need for the creation of a specific user

My use case is a searxng instance, using the default conf [2]. Haven't
been able to restart it yet but this is irrelevant.

[1]
https://uwsgi-docs.readthedocs.io/en/latest/Systemd.html#one-service-per-app-in-systemd
[2] https://docs.searxng.org/admin/installation-uwsgi.html

Hi,

I'm not sure how an app that is not socket activated would be required
but I'll document how to achieve this.

Well there are Debian or derivatives users not using systemd, so no, not
dropping this part.

DynamicUser=yes does not require the creation of a specific user but will
add a note on it.

Thanks,

Alex

Ok got confused by uWSGI doc which does not make use of DynamicUser

Regards

Hi,

No, it is not enough, a multiple things are missing.

First, the section "Initscript for running uWSGI daemon" has to be
dropped as it is misleading, especially when old init script doesn't
work:

    /etc/init.d/uwsgi start
    Starting uwsgi (via systemctl): uwsgi.serviceFailed to start
     uwsgi.service: Unit uwsgi.service not found.
     failed!

Second, socket's path was changed, thus enabling .socket unit is not
enough, as one need to change nginx's (in my case) config. The old
System-V init script for apps-enabled/cgi.ini sets:

    /run/uwsgi/app/cgi/socket

Now it is created by .socket unit (and from apps-available) as:

    /run/uwsgi/cgi.socket

This change for existing configs is not mentioned too.

Third, the old init script starts the app with default.ini, now it is
not included, thus some options can be missing now and it needs
inspection. It is not mentioned too.

Fourth, not as important, but why both units are enabled? Enabling
.socket unit must be enough, worst enabling .service unit can be
misleading, as stopping it will not be enough, as .socket unit will
start it again on socket access. Remove enabling .service from README.
And simplify that enable & start by "enable --now"

Last and IMO most important, the NEWS is missing, after upgrade all
previously configured uwsgi apps just do not start (uwsgi.service unit
is missing as you can see in first snippet). It was enabled by some
systemd's magic, and thus after upgrade (and restart) one can notice
this too late. That is not expected...

BTW, consider remove the /etc/uwsgi/apps-enabled directory from package
at all, it is not needed anymore...

regards

Hi,

For instance for radicale, see https://bugs.debian.org/1130672 .

Then please suggest some proper writing!

Again, not sure the sysv init conf and doc should be dropped, maybe
moved to some legacy §. These might be used in Debian derivatives.

Good catch, simple fix.

This is difficult to fix as I do not know how this might be used
by users.

Good catch, this line is in fact useless.

I see your point but this is caused by the systemd upgrade, not any change
in uwsgi, so I would not know which version of uwsgi to attach that NEWS to...

Again, not sure about removing sysv init conf.

Thanks!

Alex

Ahoj,

Dňa Sat, 14 Mar 2026 11:46:20 +0100 "Alexandre Rossi"
<niol@zincube.net> napísal:

I described that ;-) My English is not enough to do it better.

Please do not fix it now. I guess that multiple people fixed this
already in his configs. Just mention that in readme for others.

Sure, just mention it, to people can know about this change.

I see, but the uwsgi is directly affected, thus worth to do it, not a
lot of words, just mention that things changed. IMO, most people will
be able to do proper action, but they must know that something happened
without hard debugging.

Note, that sysv init script doesn't work, as it is not real SysV
script, it just call systemd's service, which is not generated now...

regards

After a few hours of debugging, I believe this is the issue killing
radicale on Freedombox in testing after a reboot, and find it best to
flag it as affecting those.

Not quite sure how to get it running yet.  The
/usr/share/doc/uwsgi-core/README.Debian recipe has not been able to
get radicale starting yet, but I'll keep trying.  I might just have to
downgrade systemd for now, to get my calendar back.

[Petter Reinholdtsen]

I am happy to report that downloading and 'dpkg -i'-installing the set
(libnss-systemd libsystemd-shared systemd-sysv libsystemd0 libudev1
systemd-userdbd libsystemd0.1 systemd udev systemd-resolved
systemd-timesyncd libpam-systemd systemd-cryptsetup) of packages (had to
install all of them due to inter-package dependencies) from
<URL: https://snapshot.debian.org/package/systemd/259.1-1/ >, 'service
start uwsgi' worked and radicale is available again.  I added 'apt-mark
hold libsystemd0 libudev1' to avoid accidential upgrades for now.

Thus it seem to be clear what triggered the missing calendar server on
freedombox.  How to properly solve it, on the other hand...

Hi,

Here is my try[1].

[1] https://salsa.debian.org/uwsgi-team/uwsgi/-/commit/415799b093779922c259449a3fee77c322417a6f

Thanks,

Alex