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]
