Hi, On Fri, Feb 12, 2016 at 10:36 PM, Lennart Poettering <[email protected]> wrote: > On Fri, 12.02.16 23:12, Mikhail Kasimov ([email protected]) wrote: > >> 12.02.2016 22:57, Lennart Poettering пишет: >> > On Fri, 12.02.16 22:28, Mikhail Kasimov ([email protected]) wrote: >> > >> >>> TimeoutStopSec= is set to 90s by default. Because it is opt-out and >> >>> not opt-in it's set pretty much in all cases. >> >>> >> >>> Note that when the RuntimeMaxSec= timeout hits and systemd starts >> >>> terminating the service it does so by going through ExecStop= and >> >>> ExecStopPost=. The TimeoutStopSec= timeout applies to each of them >> >>> anyway. >> >> >> >> So, if systemd is going through ExecStop= and ExecStopPost= to stop unit >> >> with RuntimeMaxSec=, which is the normal procedure to exit with >> >> on-success exit-code, why systemd marks unit as "failed", when >> >> RuntimeMaxSec= is hit? Can't catch the logic yet... >> > >> > It's the same as with a daemon exiting non-zero. In that case we'll >> > also continue with ExecStop= and place the service in a failed state. >> >> So, if I define, for example, RuntimeMaxSec=15s, that means unit should >> stop its job in the interval=[0; 14.59]s and 15.00s will be interval >> overflow with exit-code 'failure'. OK. But what if unit will stop its >> job on, e.g., 13th second? Exit-code=success? > > Yes. > > RuntimeMaxSec= just says "abort this shit if it takes longer than > this". The usecase is to use it for stuff which is not supposed to > take this long, and where it's better to abort it, and complain than > to leave it running unbounded.
What is a use case for this, can you give an example? I can make few for a Type=oneshot service (Note that this setting does not have any effect on Type=oneshot services) like "send this email, search this database" but I cannot come up with something for other service types. However I think it would be nice to extend this to terminate say a service taking all available CPU within certain time. Umut > > Lennart > > -- > Lennart Poettering, Red Hat > _______________________________________________ > systemd-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/systemd-devel _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
