Bug#1003641: systemd-oomd.service already active, refusing

[Michael Biebl]

Am 13.01.22 um 08:36 schrieb Jérémy Lal:

Package: systemd-oomd
Version: 250.2-2
Severity: normal

Hi,

i've installed systemd-oomd 250.2-1 and on upgrade,
noticed this:

systemd-oomd.socket: Socket service systemd-oomd.service already active, 
refusing.
Failed to listen on Userspace Out-Of-Memory (OOM) Killer Socket.

I'm not sure what should be done. Stop the service, disable the socket ?

The behaviour of dh_installsystemd is to treat systemd-oomd.service and
systemd-oomd.socket as completely separate services.




What you see is basically a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955483







This is untested:

override_dh_installsystemd:
...     
        dh_installsystemd -Psystemd-oomd systemd-oomd.service


(not quite sure if we need --no-restart-after-upgrade as well).





Balint had some thoughts in #955483, but nothing really happened since then

So it generates code for both units to enable/disable and restart those units (more or less independently). You can't really restart a socket unit though which is bound to a running service. We don't have a good answer here. This probably needs support from upstream as well. As a workaround, we could probably drop the restart/start of systemd-oomd.socket and only keep the enable/disable/stop-on-removal bits. For that we'd need separate calls to the dh_installsystemd override. One for systemd-oomd.service and one for systemd-oomd.socket. dh_installsystemd -Psystemd-oomd --no-start --no-stop-on-upgrade systemd-oomd.socket This has the downside that the socket is no longer restarted on upgrades, so changes to the socket unit are not applied. It has the upside, that it doesn't interfere with the currently running .service unit. Ideally, this would be handled better by systemctl and/or debhelper by knowing that those units belong together and restarting them in the correct order.

OpenPGP_signature
Description: OpenPGP digital signature