Hi Umut,

thx for answering

> -----Original Message-----
> From: Umut Tezduyar Lindskog [mailto:u...@tezduyar.com]
> Sent: Monday, March 02, 2015 8:51 PM
> To: Hoyer, Marko (ADITG/SW2)
> Cc: systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] Service watchdog feature in state
> ACTIVATING ?
> 
> Hi Marko,
> 
> On Sunday, March 1, 2015, Hoyer, Marko (ADITG/SW2) <mho...@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
>       mho...@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@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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to