[systemd-devel] [EXT] Re: Q: "Industry Standard" unit files

[Mantas Mikulėnas]

On Tue, Aug 3, 2021 at 1:28 PM Ulrich Windl <
Ulrich.Windl at rz.uni-regensburg.de> wrote:

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

The mapping of exit codes can be overridden -- if the process itself
considers 1 and 3 to be successful, then "SuccessExitStatus=0 1 3" would
help.

Prefixing the command with a "-" (as in "ExecStart=-/opt/foo") 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).

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20210803/a8b91089/attachment-0001.htm>