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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 06, 2014 at 03:21:33PM +0000, Simon McVittie wrote:
> On 06/11/14 14:16, Zbigniew Jędrzejewski-Szmek wrote:
> > What matters is how it is all arranged:
> > 
> > - if there's a job that does stuff, and then calls reboot or shutdown
> > - a hook into the shutdown or reboot target does some work
> 
> unattended-upgrades is currently the latter: the user shuts down (or is
> reminded to shut down by an update notification), and
> unattended-upgrades runs as a side-effect.
> 
> This is an optional (non-default) configuration of an optional package,
> not core Debian/Ubuntu functionality; so it doesn't necessarily have to
> be like this forever, it could be modified to tell systemd "I'm still
> shutting down, continue to wait" periodically, it could be modified to
> use "reboot into a special mode, install, then reboot again" logic under
> systemd if that's something you already have, and, worst-case, it could
> install a drop-in to override the timeout.
> 
> The default configuration is currently to perform the upgrades in-place
> and prompt the user to reboot when convenient, just like a manual
> apt/zypp/etc. run would.
> 
> I have worked on improving u-u's upgrade-during-shutdown mode for
> SteamOS, where it is actively used in that mode (SteamOS doesn't use
> systemd yet, as far as I know). With my patchset, it pre-downloads all
> necessary packages and performs a pre-prepared transaction during
> shutdown. Without my patchset, it downloads stuff during shutdown, which
> seemed rather more precarious than anyone wants.
Hm, so maybe I was a bit hasty with the revert. It doesn't really matter
if download+updates or just updates are done during shutdown. In either
case, a fixed timeout is dangerous.

Zbyszek