<div dir="ltr"><div dir="ltr">On Tue, Aug 3, 2021 at 1:28 PM Ulrich Windl <<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-regensburg.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>>> Mantas Mikulenas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>> schrieb am 03.08.2021 um 11:44 in<br>
Nachricht<br>
<<a href="mailto:CAPWNY8X30TZmEGMvGugM6Ht-oM%2B1p4OqJ0-3iXyHT1cegho1fQ@mail.gmail.com" target="_blank">CAPWNY8X30TZmEGMvGugM6Ht-oM+1p4OqJ0-3iXyHT1cegho1fQ@mail.gmail.com</a>>:<br>
> On Tue, Aug 3, 2021, 11:36 Ulrich Windl <<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de" target="_blank">Ulrich.Windl@rz.uni-regensburg.de</a>><br>
> wrote:<br>
> <br>
>> Hi!<br>
>><br>
>> I'm not into socket units, but maybe one one is could have a look at the<br>
>> unit files shown in <a href="https://serverfault.com/q/1070757/407952" rel="noreferrer" target="_blank">https://serverfault.com/q/1070757/407952</a>. Those files<br>
>> are from a commercial product (Backup Software)<br>
>> I wonder if these look OK, or (what I think) are quite incomplete.<br>
>><br>
> <br>
> Looks mostly OK to me.<br>
> <br>
>><br>
> A dependency on network is not needed for sockets with wildcard binds (i.e.<br>
> just port, no specific IP address). These will always succeed.<br>
> <br>
> The service doesn't need a general network dep either, if you've received a<br>
> connection then the network is usually already up.<br>
> <br>
> Dependency on local-fs is implied in DefaultDependencies, *I think,* so you<br>
> don't need to explicitly add it. Although maybe<br>
> RequiresMountsFor=/var/opt/omni would be useful.<br>
> <br>
> I wouldn't expect the vendor to include a dep on remote-fs by default. It's<br>
> up to the admin to decide this – locally adding dependencies is quite a bit<br>
> easier than locally removing unwanted ones (I really wish unit files had a<br>
> -= operator, but.) Having things depend on NFS when they don't actually<br>
> need it is annoying.<br>
> <br>
> On the other hand, I would *remove* some options – that PIDFile= is<br>
> redundant in general, and just outright makes no sense for a templated@<br>
> service to use a non-templated pidfile path. The KillMode=process is also<br>
> somewhat dubious.<br>
> <br>
> PartOf=omni.service doesn't seem like it would work, as an Accept=yes<br>
> socket will indeed use omni@.service (one instance per connection, not a<br>
> single long-running daemon – this very much looks like a direct conversion<br>
> from inetd-based service to systemd). I'd remove it here.<br>
> <br>
> Similarly, the WantedBy= in omni@.service is nonsensical – inetd<br>
> per-connection services can't be started on boot, there's no connection to<br>
> attach them to... This kind of service has to be started by the socket, not<br>
> through `systemctl enable`.<br>
<br>
Thanks for having a look! So it seems not as broken as I was afraid.<br>
You are right that the service was written for inetd originally, and one of<br>
the problems found with systemd is that the process ends with varying exit<br>
codes (mostly 1 and 3) that systemd considers to be not successful.<br></blockquote><div><br></div><div>The mapping of exit codes can be overridden -- if the process itself considers 1 and 3 to be successful, then "<font face="monospace">SuccessExitStatus=0 1 3</font>" would help.</div><div><br></div><div>Prefixing the command with a "-" (as in "<font face="monospace">ExecStart=-/opt/foo</font>") is also an option, if you want to ignore *all* exit codes; many inetd-converted services do this to avoid accumulating failed instances (e.g. after botnet probes).</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>