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

[Lennart Poettering]

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.

I think we should find good defaults, that work for most cases, and
make things robust in the common case. Now, an fsck or selinux relabel
taking a long time is a pretty common case, we shouldn't break that,
hence I figure turning off the boot timeout is probably a good
idea. However, doing unattended upgrades at shutdown is not really a
common case.

Lennart

-- 
Lennart Poettering, Red Hat