On Mon, Mar 17, 2008 at 09:22:53PM +0100, Stefan Fritsch wrote: > > dh_installinit's default behaviour should be to not stop daemons, > > but to issue a reload, restart, or force-restart in the .postinst. > > JFTR, doing a simple reload on upgrade is _always_ wrong. After an > upgrade the new executables must be running, not the old ones. For > example, the old executables might still contain security issues.
true. a restart in the postinst, not reload, is the appropriate action. > And the current debhelper behaviour is the safer way and should be the > default. A daemon crashing because some of its data files no longer > fit to the running process can cause much more severe data loss than > just some down time. that is the appropriate behaviour ONLY for those particular daemons where that actually happens. for daemons like bind9 and rsyslog and most others, it is the wrong behaviour - it maximises downtime, disrupts the entire network (for named) and causes irreplacable data loss (for rsyslog). if downtime is unavoidable, then it's unavoidable - nothing can be done about it, it just has to be accepted. but where it IS avoidable, then it SHOULD be avoided...and, in either case, downtime should be minimised. if there are a known set of packages which have this behaviour then either (a future version of) apt or dpkg could prioritise them (perhaps via some tag in the control file) so that they and their dependancies are unpacked and configured before other unprioritised packages. or, even without any explicit support in apt or dpkg, a local sysadmin could write a shell script to upgrade just those daemon packages first before doing a full dist-upgrade. or upgrade them manually (which is what i have to do now for bind9. and squid. and now also for rsyslog). but that's only possible if it's a relatively small set of known problematic packages. it becomes impossible - pointless - if ALL daemons stop then start later, rather than just restart. why pointless? because the point is to upgrade and configure those problematic packages as quickly as possible, to minimise downtime. if all daemon packages do the wrong thing, then the end result would be no different to just doing a dist-upgrade. BTW, most daemon packages don't have lots of data files open. most just read a config file at startup (or on a HUP signal), and open a log file or socket. one that usually does have many data files open, postfix, restarts in the postinst...and has done so for many years without problem. > And a maintainer would have to check on every upload if and for which > old versions it is safe not to stop the daemon before replacing the > files. This would doubtless lead to many other bugs. the maintainer could do it in such a complicated manner, but it's not necessary. most such problems occur when a significant new version is released (e.g. a major version, not just a minor point release). the package maintainer could stop and then start if the old version was <= a particular version number, or just restart if it wasn't. a simpler generic method that would works reasonably well is that the maintainer would just have to know whether there was any risk of their daemon package having such problems. if there was a risk, then stop in prerm, start in postinst. otherwise, just restart in the postinst. in any case, it's only necessary for those daemon packages where there IS such a problem or risk - it's not at all necessary for most daemon packages. a simple restart in the postinst will suffuce. craig -- craig sanders <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
