[systemd-devel] [systemd-commits] units/basic.target units/poweroff.target units/reboot.target

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 06, 2014 at 02:28:12PM +0100, Lennart Poettering wrote:
> On Thu, 06.11.14 12:45, Patrick Häcker (pat_h at web.de) wrote:
> 
> > > > However, this one appears bogus to me. Is there any such software
> > > > around that really does this? And if so, this really appears weird to
> > > > me to support. Delaying shutdown for more than 30min is just wrong.
> > > Isn't this what the various "download updates and reboot" gnome-y
> > > things are doing?
> > At least unattended-upgrades from Debian/Ubuntu/... can be configured to 
> > install updates on shutdown (without any special mode or something). And, 
> > yes, this can run for more than 30 minutes, which I could already observe in 
> > its default mode (installing during normal system activities), so I see no 
> > reason why this should not happen when configured to install during shutdown. 
> > The reason is, that unattended-upgrades can basically update the whole 
> > distribution to the next version, which naturally can take a lot of time.
> > 
> > It's questionable if this is a sane setup, but I can think of setups where 
> > this might be useful, e.g. having two identically configured servers for 
> > redundancy reasons where one server would be enough. Then it might make sense 
> > to update one system during shutdown while the other one takes over. This has 
> > the advantage, that normally running servers either have the old or the new 
> > state, but never some intermediate state during the update. The shutdown time 
> > does not really matter in this case and a watchdog killing the system 
> > wouldn't be welcome. But all in all this seems like an exotic use
> > case.
> 
> Is "unattended-upgrades" a package of its own? If so, I'd probably ask
> the packagers to include drop-ins for reboot.target to override the
> timeout. That way, as soon as you install it the shutdown timeouts are
> disabled.
That is suboptimal. There really should be a way to this dynamically, like saying:
I'm a log-running job, I need more time, but everything is still fine. This
type of status should require periodical pings, watchdog style. Let's say that
the backup job run during shutdown hangs because there's no network, we want
to shutdown at some point anyway.

Zbyszek