[systemd-devel] Service watchdog feature in state ACTIVATING ?

[Hoyer, Marko (ADITG/SW2)]

> -----Original Message-----
> From: Lennart Poettering [mailto:lennart at poettering.net]
> Sent: Wednesday, April 22, 2015 6:00 PM
> To: Hoyer, Marko (ADITG/SW2)
> Cc: Umut Tezduyar Lindskog; systemd-devel at lists.freedesktop.org
> Subject: Re: [systemd-devel] Service watchdog feature in state
> ACTIVATING ?
> 
> On Mon, 02.03.15 20:32, Hoyer, Marko (ADITG/SW2) (mhoyer at de.adit-
> jv.com) wrote:
> 
> > > Why would you need this? Watchdog is to prevent system being stuck
> > > somewhere. If activation fails within TimeoutStartSec=, systemd
> will
> > > put the service in "failed to activate" state anyways.
> > >
> > > Is waiting 20 seconds to detect the freeze is too much for your
> case?
> > > Is it not possible to lower the activation time?
> >
> > Yes it is too long. The process is a kind of application starter and
> observer processing a startup phase. It is responsible for:
> > - observing the application internal states of upcoming applications
> > - it kicks off the startup of applications depending on the internal
> > state of other once
> > - it delays the startup of late services started the normal way by
> > systemd once the startup phase is done
> >
> > And yes, one could say that we are implementing a kind of second
> > systemd started by systemd. The difference is that our starter knows
> > about some more states than just ACTIVATING and RUNING which is not
> > really realizable with systemd especially when more than one
> > "application" is contained in one process.
> >
> > So the idea was to bring up a set of applications with our starter
> > application and stay with our starter in state ACTIVATING until it is
> > done with bringing up the set of applications.
> >
> > Depending on the product, bringing up our set of applications can
> take
> > 10-20secs. Since the starter is a kind of sensible application, it
> > needs to be supervised by a watchdog with a timeout far less than
> > 20secs.
> >
> > Hope this gives a rough picture of our use case.
> 
> So, I can see that having watchdog support during the activating phase
> might make sense in this case, but I am not sure this case is strong
> enough to add it to systemd proper, since it would complicate things
> for most: it's not a behaviour we can just enable for everybody, it
> would have to be something we'd have to add an explicit opt-in option
> for, since most daemons don't work like this.

Thx for getting back to this again.

An a bit more light weight variant could be adding a second watchdog timeout parameter meant for the activation phase only. This timeout value could be 0 (infinite) by default. This way, the feature is probably invisible for all who are not explicitly setting it. 

> Anyway, I'd prefer not adding support for this now. We can revisit this
> if more folks are asking for this, and this turns out to be a more
> common setup.

Sounds good.

Best regards

Marko Hoyer
Software Group II (ADITG/SW2)

Tel. +49 5121 49 6948