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

[Hoyer, Marko (ADITG/SW2)]

Hi Umut,

thx for answering

> -----Original Message-----
> From: Umut Tezduyar Lindskog [mailto:umut at tezduyar.com]
> Sent: Monday, March 02, 2015 8:51 PM
> To: Hoyer, Marko (ADITG/SW2)
> Cc: systemd-devel at lists.freedesktop.org
> Subject: Re: [systemd-devel] Service watchdog feature in state
> ACTIVATING ?
> 
> Hi Marko,
> 
> On Sunday, March 1, 2015, Hoyer, Marko (ADITG/SW2) <mhoyer at de.adit-
> jv.com> wrote:
> 
> 
> 	Hi,
> 
> 	I ran into a use case where the activation phase of a service
> takes significantly longer than the desired watchdog period
> (Activating: 10-20secs, Watchdog: 1-5secs).
> 
> 	I found out that the watchdog features starts not before the
> service is in state START_POST. This means for my use case that the
> system is blind for 10-20secs (whatever I set as startup timeout here).
> 
> 	Is there any way to activate the watchdog feature already in
> phase ACTIVATING?
> 
> 
> 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.

> 
> Umut
> 
> 
> 	I guess there should be a second watchdog configuration parameter
> to allow services to use different values for the states ACTIVATING and
> RUNING. Otherwise, people who are not interested in having a watchdog
> observation during startup will run into troubles ...
> 
> 	Any opinions on that?
> 
> 
> 	Best regards
> 
> 	Marko Hoyer
> 
> 	Advanced Driver Information Technology GmbH
> 	Software Group II (ADITG/SW2)
> 	Robert-Bosch-Str. 200
> 	31139 Hildesheim
> 	Germany
> 
> 	Tel. +49 5121 49 6948
> 	Fax +49 5121 49 6999
> 	mhoyer at de.adit-jv.com <javascript:;>
> 
> 	ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch
> Car Multimedia GmbH and DENSO Corporation
> 	Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB
> 3438
> 	Geschaeftsfuehrung: Wilhelm Grabow, Katsuyoshi Maeda
> 	_______________________________________________
> 	systemd-devel mailing list
> 	systemd-devel at lists.freedesktop.org <javascript:;>
> 	http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
Best regards

Marko Hoyer
Software Group II (ADITG/SW2)

Tel. +49 5121 49 6948