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

2015-04-22 Thread Lennart Poettering
On Mon, 02.03.15 20:32, Hoyer, Marko (ADITG/SW2) (mho...@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.

I mean, in most cases the start-up phase of a daemon is relatively
quick, and the daemon will not enter its event loop before the
start-up is complete. But it is the event loop that normally needs to
process watchdog events.

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.

I hope that makes sense,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2015-04-22 Thread Hoyer, Marko (ADITG/SW2)
 -Original Message-
 From: Lennart Poettering [mailto:lenn...@poettering.net]
 Sent: Wednesday, April 22, 2015 6:00 PM
 To: Hoyer, Marko (ADITG/SW2)
 Cc: Umut Tezduyar Lindskog; systemd-devel@lists.freedesktop.org
 Subject: Re: [systemd-devel] Service watchdog feature in state
 ACTIVATING ?
 
 On Mon, 02.03.15 20:32, Hoyer, Marko (ADITG/SW2) (mho...@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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2015-04-22 Thread Lennart Poettering
On Wed, 22.04.15 17:59, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-jv.com) wrote:

  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.

Well, if it's a boolean or a timeout that is configured, I'd prefer
not to add either option unless this turns out to be a frequently
requested feature...

I am just careful with adding even more settings so easily...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2015-03-02 Thread Hoyer, Marko (ADITG/SW2)
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


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

2015-03-02 Thread Umut Tezduyar Lindskog
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?

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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2015-03-01 Thread Hoyer, Marko (ADITG/SW2)
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?
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

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
http://lists.freedesktop.org/mailman/listinfo/systemd-devel