I'm stuck with 3rd party startup scripts. I was confused by the systemd-service documention for Type Type= If set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up
As far as I could see, the 3rd party scripts do not use fork. Thanks, Stephen R. Owens Senior Software Engineer Massachusetts Office of Information Technology Commonwealth of Massachusetts One Ashburton Place, Room 1611 Boston, MA 02108 Tel: 617-626-4513 x24513 Email: stephen.ow...@state.ma.us -----Original Message----- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Tuesday, December 20, 2016 12:28 PM To: Owens, Stephen (MassIT) Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] systemctl status and service unit configuration with startup script that exits On Tue, 20.12.16 17:10, Owens, Stephen (MASSIT) (stephen.ow...@mass.gov) wrote: > [Service] > Type=oneshot > RemainAfterExit=yes Type=oneshot is for services that run at boot and exit at boot. i.e. stuff that generally doesn't stay around, stuff like fsck or so which runs and exits before the boot proceeds. If you service spawns processes that stay around use Type=forking or so. > KillMode=none This is a hack. Don't use this. If you use the right Type= (as discussed above), then you don't need to explicitly disable systemd's service tracking. > The Main PID: 15346 I assume was the pid for the startup script which exits. > Is there some way I can have systemd monitor the component pids to show > ACTIVE status? > Is there a better way to configure the service unit - given that we have to > use the 3rd party scripts? Well, the systemd model is to expose each daemon as one seperate .service. In your case however you appear to wrap two daemons in a single service. This will always be awkward. In particular as systemd only considers a single PID the "main PID" of a service (well, in fact there may be zero or one main PIDs, but not more), which doesn't map at all to your case, since you have two PIDs that could be considered "main". Any such mapping will hence be a bit off, and systemd won't notice when your daemons stop (unless they both stop), and hence Restart= and things like that won't work, and neither will runtime failure detection. My recommendation is: fix this properly, write two separate service units, it's the better choice, in particular in the long run. If you do, then systemd can properly track the service in all details. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel