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

Felipe Sateler fsateler at debian.org
Thu Jan 13 16:56:39 GMT 2022


On Thu, Jan 13, 2022 at 10:03 AM Michael Biebl <biebl at debian.org> wrote:

> 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.
> 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.
>
> What you see is basically a duplicate of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955483
>
> 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.
>
> This is untested:
>
> override_dh_installsystemd:
> ...
>         dh_installsystemd -Psystemd-oomd systemd-oomd.service
>         dh_installsystemd -Psystemd-oomd --no-start --no-stop-on-upgrade
> systemd-oomd.socket
>
> (not quite sure if we need --no-restart-after-upgrade as well).
>
> 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.
>
>
I believe the ultimate fix is to actually fix
https://github.com/systemd/systemd/issues/8102 upstream. AFAICT, that would
resolve everything?


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

-- 

Saludos,
Felipe Sateler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20220113/4a59628e/attachment.htm>


More information about the Pkg-systemd-maintainers mailing list