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
