<div dir="ltr"><div><div>Hi!<br><br></div>Thank you very much!<br><br></div><div>It just shows that I was never patient enough to actually test it long enough to hit 30min timeout (after about 15 min I generally would reset the system).<br></div><div>The  JobTimeoutSec is a good candidate to be reduced to something like 5 min for our use case.<br><br><br></div><div>Best regards.<br><br><br></div><div>Sergei.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 31 March 2017 at 05:52, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 09.03.17 13:00, Sergei Franco (<a href="mailto:sergei.franco@gmail.com">sergei.franco@gmail.com</a>) wrote:<br>
<br>
> Hello!<br>
><br>
> Thank you very much for pointing out the "After" vs "Before", as in for<br>
> ExecStop to run Before filesytem is unmounted it must be configured as<br>
> After :).<br>
> This fixes the Ubuntu unattended upgrades unit that prevents from hanging.<br>
><br>
> What I would like to address for future problems like this is how to have a<br>
> global timeout where systemd gives up and reboots anyway (regardless the<br>
> state of the units)? Even if it is a dirty reboot.<br>
<br>
</span>We have that in place. It's configured to 30min however, in order to<br>
be friendly to super-slow databases.<br>
<br>
See "systemctl cat reboot.target":<br>
<br>
    …<br>
    JobTimeoutSec=30min<br>
    JobTimeoutAction=reboot-force<br>
    …<br>
<span class="HOEnZb"><font color="#888888"><br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Red Hat<br>
</font></span></blockquote></div><br></div>