On Tue, Mar 18, 2008 at 04:01:05AM +0100, Michael Biebl wrote: > Craig Sanders wrote: > > On Sun, Mar 16, 2008 at 03:14:58AM +0100, Michael Biebl wrote: > > > > Second, if you replace files while the daemon is still running, > > > this can lead to all sorts of subtle failures, e.g. daemons that > > > dynamically load functionality via shared modules (as rsyslog does) > > > might crash. > > > > 'MIGHT crash' is a whole lot better than 'definitely WILL be shut down > > for the entire duration of the upgrade - many minutes or even hours(*)'. > > > > with the former you have a chance of significant downtime during > > upgrade. > > > > with the latter, you are guaranteeing significant downtime during > > upgrade. > > The difference is, that a crashing daemon might lead to data corruption, > which is much worse than a slightly longer downtime.
1. with rsyslog - or any other daemon that writes to sequential text files - data loss is as bad as data corruption. and rsyslog's current behaviour during upgrade guarantees long duration downtime and long duration data loss. a guarantee of data loss is worse than just the risk of same. 2. you seem determined to deliberately miss the point. i am NOT saying that it is *ALWAYS* bad to stop a daemon in the prerm and start it in the postinst. i am saying that it is bad to do it in cases where there is no demonstrated need. and I am saying that it is bad to do that simply because it is the default behaviour of debhelper's dh_installinit without even thinking about it or, worse, because logical deduction based on false premises (that most daemons are at risk of this problem) leads you to a false conclusion (that stopping early and starting late is the correct default behaviour). for the tiny minority of daemons where there is risk of data loss if the upgrade is not performed in a particular manner, it is entirely appropriate to do whatever is necessary to ensure safe and reliable upgrade....including stop-early,start-late. for the vast majority of daemons, where there is no such risk, the correct behaviour is to just restart in the postinst as that will minimise downtime and, in cases like rsyslog, minimise loss of data. not only is it the correct behaviour, it should be the default behaviour - simply because it IS the correct behaviour in all but a handful of exceptional cases. > FWIW, if it is correct, that postfix behaves the way you describe, than > this is broken. no, it's not. postfix does the right thing. > [ mistaken understanding deleted ] > The only reasonable and safe choice is, to > stop postfix in prerm before those other services. 1. if you don't know how mail works, or how postfix works, then you really shouldn't claim to know what is the "only reasonable and safe choice". 2. there's no way of guaranteeing that postfix will be upgraded before, say, mysql or postgresql without making those packages Pre-Depend on postfix. which would be absurd, most people who use either db don't use it for postfix. e.g. in a dist-upgrade, mysql is lower in sort order so will likely upgrade before postfix. postgres is slightly higher than postfix, so will likely upgrade after postfix. 3. for those users who have created such inter-dependancies on their own system, they know - or should know - the correct order to upgrade the packages that are important to them. they have specific needs, so it is up to them to handle them appropriately....but it is wrong to force ordinary users who don't have such specific needs to jump through those same hoops. craig -- craig sanders <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
