Bug#679853: general: Too much downtime during a big dist-upgrade - avoidable with snapshots
> While it might work for some, there's a much simpler way to minimize
> daemon downtime: Avoid stopping a daemon in the prerm, and instead
> restart it in the postinst. Downtime then becomes < 1 second per daemon
> (less than a kexec reboot).
> However, the daemon then needs to be audited to ensure that it will
> continue to work while its foundation is being upgraded underneath it.
Yes, you seem to be right here. That's what I did for my own
proprietary daemon that also runs on my debian servers, and it works
well enough (except that I need to restart it manually when the shared
libraries it uses receive security updates - but that's OK for me).
So in reality, I am on the fence. The quoted solution is easier and it
seems to work well enough. But for some reason, freedesktop folks
invented this for desktop systems:
http://fedoraproject.org/wiki/Features/OfflineSystemUpdates . From
what I have understood, the motivation is that there is no way to get
a consistent state except by rebooting - which partially corresponds
to your case of non-audited daemons. Basically, it looks like they
gave up, that's why I proposed a complicated solution based on the
same shaky (at least for servers) assumption that it is the best to
avoid updating packages on a live system.
As for the issue of merging files e.g. in /etc - the objection is
valid if there is a valid source of such changes (and IMHO indeed, it
would be too radical to ban any manual changes in /etc between the
upgrade and the reboot).
Also, for anyone reading this bug, I would like to stress that I
consider it an issue only for systems running the testing
distribution, because big dist-upgrades are not frequent in stable.
--
Alexander E. Patrakov
Reply to: