severity 471051 critical
thanks
this bug can not be downgraded to normal because it is a bug that
results in a loss of important and irreplacable data. that is one of the
defining characteristics of a critical bug. loss of logging also has
security implications, which is also a critical issue.
On Sat, Mar 15, 2008 at 03:32:00PM +0100, Michael Biebl wrote:
> Craig Sanders wrote:
> > Package: rsyslog
> > Version: 2.0.3-1
> > Severity: critical
> > Justification: causes serious data loss
> >
> >
> > rsyslog shuts down at the start of the upgrade and only gets restarted
> > when the package is configured.
> >
> > this is broken. instead of stopping rsyslog in the prerm and starting it
>
> Well, this is standard behaviour on Debian: daemons are stopped before
> upgrade and started after the upgrade.
no, it is not and never has been standard behaviour on debian.
i've been a DD for over 10 years, and it's only recently that some
daemons have been doing this on upgrade rather than reloading/restarting
in the postinst. in fact, most still do just a reload/restart.
there is NO NEED WHATSOEVER to stop a daemon just because it is being
upgraded.
it is only if the package is actually being removed or purged, not just
upgraded, that it needs to be stopped.
> With your reasoning, you'd have to file bug reports against all of
> them (say mysql, postgresql, you name it).
yes, of course. IF they do the same thing.
downtime for them should be minimised too.
postgres, unfortunately, does - at least 8.3 does and possibly other
recent versions. it never used to.
i know that bind9 does. i've already filed a bug report against it. did
that back in december when i first noticed it. when it is stopped
during upgrade, there is no DNS service for the network it is serving
until it is configured in the postinst.
mysql doesn't.
postfix, like MOST other daemon packages i use, also doesn't. postfix's
.prerm script[1] is a good example of correct behaviour. see below.
the root cause of the bug is misuse of dh_installinit. i've already
filed a bug against debhelper because its default behaviour for
dh_installinit causes this broken-ness.
[1] /var/lib/dpkg/info/postfix.prerm:
---cut here---
# Debian Postfix postrm
# LaMont Jones <[EMAIL PROTECTED]>
case "$1" in
remove)
ldconfig
dpkg-statoverride --remove /usr/sbin/postdrop >/dev/null 2>&1 || true
dpkg-statoverride --remove /var/spool/postfix/public >/dev/null 2>&1 || true
dpkg-statoverride --remove /usr/sbin/postqueue >/dev/null 2>&1 || true
;;
upgrade)
;;
purge)
rm -rf /var/spool/postfix
rm -rf /etc/postfix
update-rc.d postfix remove >/dev/null
userdel postfix >/dev/null 2>&1 || true
groupdel postdrop >/dev/null 2>&1 || true
groupdel postfix >/dev/null 2>&1 || true
;;
failed-upgrade|abort-install|abort-upgrade|disappear)
;;
*)
echo "postrm called with unknown argument \`$1'" >&2
exit 1
;;
esac
# Automatically added by dh_installdebconf
if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
. /usr/share/debconf/confmodule
db_purge
fi
# End automatically added section
# Automatically added by dh_makeshlibs
if [ "$1" = "remove" ]; then
ldconfig
fi
# End automatically added section
---cut here---
(and yes, i can see that the comments and echo message mentions postrm,
but this *IS* from the prerm script. it's just a copy-and-paste error,
the code was edited but the comments weren't)
many other daemon packages do the same or similar thing. THIS is
the standard behaviour in debian, not misuse of dh_installinit.
> One of the reasons, why it is done this way, ist that you can't
> guarantee a clean shutdown of the daemon, when you have replaced it's
> files, while it is still running.
name one daemon where that's a case.
that might be an issue in some extremely unusual package, but not in
most. and that unusual package can handle things as it needs to.
i.e. if it happens at all, it's a special-case, an exception and NOT the
rule.
other packages should opt for minimal downtime, minimal loss of data.
> So stopping the old daemon in prerm and starting the new one in
> postinst, seems like the "more correct" solution to me.
no, it's the LEAST correct solution because it maximises downtime during
upgrade, resulting in loss of service and loss of data.
> Example: The current rsyslog package uses a separate binary "rklogd" to
> log the kernel messages. This binary is started/stopped via
> /etc/init.d/rsyslog.
> The next major release of rsyslog will implement the kernel log
> functionality as loadable modules, so there is no more rklogd.
> That means, I have to stop rsyslog with the correct (i.e. old) init
> script, to cleanly shutdown rsyslogd and rklogd and start the new
> rsyslogd with the new init script.
no, you don't HAVE TO do that at all.
the correct thing to do is to handle that as a special case in the
postinst script - check if rklogd is running, stop it if it is, and then
restart rsyslogd as normal.
you don't cause lengthy downtime and data loss on every upgrade just
because it's easier to use dh_installinit's default behaviour than it is
to write a little bit of simple scripting code.
that's what if/then/else is for.
craig
--
craig sanders <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
