On Wed, Mar 27, 2024 at 9:35 AM Steve Traylen <steve.traylen@xxxxxxx> 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@.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
