[systemd-devel] Forking service behind socket and service.

Mantas Mikulėnas grawity at gmail.com
Wed Mar 27 08:54:51 UTC 2024


On Wed, Mar 27, 2024 at 9:35 AM Steve Traylen <steve.traylen at cern.ch> wrote:

> Hi,
> I have a old legacy service that's a bit odd in that it was previously
> launched by xinetd but is weird in that:
>
> After an initial quite quick auth and set up a daemon is forked of to run
> the much longer process.
>
> Setting this up with a socket me.socket and me at .service does not work
> quite right for us.
>
> In particular I want the socket to close once the fork happens.
>
> If the service is Type=forking things do work but socket is persisted -
> that's not great for thing doing the original submission. It expects the
> socket to be short lived.
>
> Only workaround I have which is rubbish for obvious reasons is to use the
> service with Type=simple, KillMode=None to leave the forked process running.
>
> Anyway to persuade the socket service to close earlier.
>
> Presumably in the xinetd world xinetd was oblivious to this forked process.
>

Well, xinetd predates the whole idea of per-service process tracking using
cgroups or whatever else; it only knows about its immediate children.

But even in the systemd world, if you have xinetd.service, everything
spawned by xinetd is still just part of xinetd.service and can continue
running as long as xinetd (the main process of the .service) keeps running.

So I would say just keep using xinetd for it? It's definitely not a good
fit for systemd .socket as you've found out, but it can continue to run
under (x)inetd or a custom `systemd-socket-activate` service (that's mainly
a CLI tool for testing but it would work as a service too).

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


More information about the systemd-devel mailing list