[systemd-devel] [ANNOUNCE] systemd v229

[Lennart Poettering]

On Fri, 12.02.16 23:12, Mikhail Kasimov (mikhail.kasimov at gmail.com) wrote:

> 12.02.2016 22:57, Lennart Poettering пишет:
> > On Fri, 12.02.16 22:28, Mikhail Kasimov (mikhail.kasimov at gmail.com) 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. 

Lennart

-- 
Lennart Poettering, Red Hat