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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
