> 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/can_lgv1l_agrrwyvmabzgbvdnqqn_2p+xxfcrlpxljtvw6z...@mail.gmail.com
