On Sun, Mar 16, 2008 at 01:16:22AM +0100, Michael Biebl wrote: > Craig Sanders wrote: > > 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. > > Do you want to play bts ping-pong?
nope, but a critical bug a critical bug. > > 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. > > You seem to be utterly mistaken here: again, nope. i've been in debian a lot longer than you have. i know what the behavior is, was, and should be. AFACIT, it is only packages that misuse dh_installinit, like yours does, which exhibit this broken behaviour. other packages, where the maintainers write their own pre/post scripts do not. > grep "invoke-rc.d .* stop" *.prerm 1. the fact that some other packages have the same or similar broken behaviour as yours does not excuse or justify your package being broken. 2. yes, i had the same initial thought, of doing a simple grep to find packages which stop the daemon in the prerm script. but, as is obvious from a little bit more thought about it, a simple grep won't tell you whether the stop command is wrapped inside an if/then or case statement, will it? so it tells you nothing useful. you have to actually examine each script to find out whether it is only stopping the daemon on a remove/purge (in which case, running the init.d script or invoke-rc.d to stop the daemin is correct behavior), or whether it's doing it all the time. in which case, it's broken behaviour - see point 1 above. > > 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. > > Please don't shout. it's emphasis, not shouting. shouting is when entire lines or paragraphs are all-caps. emphasis is when only certain words or phrases are all-caps. > > postfix, like MOST other daemon packages i use, also doesn't. postfix's > > Wrong, most packages use the way I described. some packages are broken in the way that has been described. that doesn't make it right. that just means that there are other broken packages. > >> 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. > > I already gave you one. no, you didn't. you made an assertion without any evidence, not even a single example. i'll ask again: which daemon is it that MUST be shutdown at the start of the upgrade and only started again in the postinst? note that "MUST" there. i.e. that it wont work any other way. that's not the same as "it's easier for me to do it this way" or "i didn't think about it and am just using the default behaviour of a packaging helper tool" if you can find one package that MUST do it this way, then that's a special case that must be handled appropriately by the package maintainer. it's not a reason for doing it that way for every other package. > > 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. > > Great idea, let's make our maintainer scripts an unmaintainable mess of > special cases. 1. it's not an unmaintainable mess. the postfix package has been maintained for years without exhibiting the broken behaviour of yours. on an upgrade, it keeps working without pause right up until the postinst restarts it. downtime is the absolute minimum required to restart postfix, anywhere from a fraction of a second (on lightly loaded systems with simple config) to a few seconds (on heavily loaded systems with complex postfix configuration). that's what daemon packages SHOULD do. (BTW, i know from personal experience that this is the case. i maintained the postfix-tls package for over a year back when encryption stuff couldn't go in main due to insane US crypto-export laws. encryption support has now been merged into the main postfix package, and postfix-tls has been dropped because it's no longer needed.) in fact, many other packages do it the same way that postfix does - the postfix's prerm script is based on a skeleton script which has been in common use in debian since the early days. 2. it's YOUR job as a maintainer to do the right thing for YOUR package. it's your job to think about how the upgrade procedure works and take appropriate steps to ensure that downtime is minimised and loss of service or data is avoided. debhelper and similar tools are there to help, not to substitute for thought or attention to detail. use them when they do the right thing. don't use them when they don't. in any case, special case code is (oddly enough) for handling special cases. changing a package that used to start two daemons so that it only starts one daemon that does the job of both IS such a special case, and thus needs special-case handling. > If you question the default behaviour of dh_installinit, discuss this > with the dh_installinit maintainer, but please don't act like a smart-ass. your package is broken. so i've raised the bug with your package. and the bug in your package is a critical one because it results in loss of important and irreplacable data. dh_installinit's default behaviour is also broken, so i've raised another bug against the debhelper package. craig -- craig sanders <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
