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

[Ulrich Windl]

>>> 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.

Regards,
Ulrich



> 
>>