> -----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; email@example.com > 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 firstname.lastname@example.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel