One of the template NM questions is about "how to minimize the downtime of a daemon during package upgrade (in maintainer scripts)". ssh does an "/etc/init.d/ssh restart" in postinstall, which (with luck) means that there will be *no* downtime. This doesn't seem to be necessary for allowing ssh upgrades, since running "/etc/init.d/ssh stop" over an ssh connection doesn't disconnect existing ssh connections, but only prevents establishing new connections until the next "start". This is different from how everybody else seems to do it, but does accomplish the goal.
But, Debian doesn't seem to do actively persue this goal. Of course, apt-get install <daemon-package> should always work, and really minimize the downtime, but doesn't solve the general problem for the dist-upgrade case, or for apt-get install <many-packages>, where it would be a small pain to have to figure out which packages are running daemons. The service isn't actually guaranteed to work during the upgrade anyway, even if it isn't stopped, due to the potential for inconsistencies between files on disk (eg. changed config file format, reread at each connection by a daemon child process, or interrelated files). Packages using debhelper dh_installinit end up with an "/etc/init.d/foo stop" in prerm and an "/etc/init.d/foo start" in postinst . During eg. a dist-upgrade, a maximal number of packages are "dpkg --unpack"ed, and afterwards are "dpkg --configure"d. This decidedly does *not* minimize daemon downtime, since it allows an arbitrarily large number of packages to be unpacked and configured before the daemon is restarted. debhelper intends to do what's needed with a simple interface. If it was acceptable to require more package-specific information, it would be possible to only stop the service if it wasn't provided by the new version of the package. (Since binary packages with multiple daemons are uncommon, it is more realistic to think of the same scenario with info documents, which also get registered in postinst, and deregistered in prerm). debhelper would then need an interface to specify that a daemon was included in certain previous versions of the package, and removed at some critical versions. Or, versions in which a daemon is removed (and versions between that version and the next stable release) could be required to have custom, not-generated maintscripts. This is an uncommon problem for daemons, but removal of info documents is much more frequent, and presents the same trouble. The implementation would involve the following in preinst (*not* prerm, since it may not be known in advance that those files/daemons would be removed): ver_removed=1.2-3 ( [ "$1" = "install" ] || [ "$1" = "upgrade" ] ) && dpkg --compare-versions "$2" lt $ver_removed && deregister_info && stop_server && ... # postrm abort-[install|upgrade] should re-register them, and restart # the server. With this code, the info document and server will always be available *during* upgrades of earlier versions, since dpkg uses an atomic rename(). Upgrading to the critical version correctly stops the server and deregisters the document *before* it is removed. I'm particularly interested in this question since I'm writing a document about dpkg, and, in particular, about use of maintainer scripts. I'm going through NM, and (so far) haven't been asked about this. If you don't want to spoil the fun for other NM's, you might reply to me personally, or think of the same question phrased in terms of info documents and dh_installdocs instead of daemon's and dh_installinit. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]