<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 13, 2022 at 10:03 AM Michael Biebl <<a href="mailto:biebl@debian.org">biebl@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 13.01.22 um 08:36 schrieb Jérémy Lal:<br>
> Package: systemd-oomd<br>
> Version: 250.2-2<br>
> Severity: normal<br>
> <br>
> Hi,<br>
> <br>
> i've installed systemd-oomd 250.2-1 and on upgrade,<br>
> noticed this:<br>
> <br>
> systemd-oomd.socket: Socket service systemd-oomd.service already active, refusing.<br>
> Failed to listen on Userspace Out-Of-Memory (OOM) Killer Socket.<br>
> <br>
> I'm not sure what should be done. Stop the service, disable the socket ?<br>
<br>
<br>
The behaviour of dh_installsystemd is to treat systemd-oomd.service and<br>
systemd-oomd.socket as completely separate services.<br>
So it generates code for both units to enable/disable and restart those <br>
units (more or less independently).<br>
<br>
You can't really restart a socket unit though which is bound to a <br>
running service.<br>
<br>
What you see is basically a duplicate of<br>
<a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955483" rel="noreferrer" target="_blank">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955483</a><br>
<br>
We don't have a good answer here. This probably needs support from <br>
upstream as well.<br>
<br>
As a workaround, we could probably drop the restart/start of <br>
systemd-oomd.socket and only keep the enable/disable/stop-on-removal bits.<br>
<br>
For that we'd need separate calls to the dh_installsystemd override. One <br>
for systemd-oomd.service and one for systemd-oomd.socket.<br>
<br>
This is untested:<br>
<br>
override_dh_installsystemd:<br>
...     <br>
        dh_installsystemd -Psystemd-oomd systemd-oomd.service<br>
        dh_installsystemd -Psystemd-oomd --no-start --no-stop-on-upgrade <br>
systemd-oomd.socket<br>
<br>
(not quite sure if we need --no-restart-after-upgrade as well).<br>
<br>
This has the downside that the socket is no longer restarted on <br>
upgrades, so changes to the socket unit are not applied.<br>
It has the upside, that it doesn't interfere with the currently running <br>
.service unit.<br>
<br>
Ideally, this would be handled better by systemctl and/or debhelper by <br>
knowing that those units belong together and restarting them in the <br>
correct order.<br>
<br></blockquote><div><br></div><div>I believe the ultimate fix is to actually fix <a href="https://github.com/systemd/systemd/issues/8102">https://github.com/systemd/systemd/issues/8102</a> upstream. AFAICT, that would resolve everything?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Balint had some thoughts in #955483, but nothing really happened since then<br>
<br>
<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><br>Saludos,<br>Felipe Sateler</div></div>