On 12/04/2006 11:32 p.m., Timo Sirainen wrote:
On Wed, 2006-04-12 at 11:37 +0100, Chris Wakelin wrote:
Sorry! I should have said something (particularly as I'm on the CVS mailing list so could see you changed it). I'd realised about the logging, but that's a small price to pay for being able to upgrade on-the-fly.
Perhaps an alternative is to have some way to signal the master process to re-exec itself when its binary has been replaced. Sounds tricky though, especially as would need to grab all the open pipes somehow.
I think that's all way too much trouble and has potential problems with leaking file descriptors. Dovecot 2.0 framework will have separate logging processes, and those could possibly live even after master has died until all log clients have died (I think it already works that way..)
Failing that, an alternative kill signal sounds like the way to go.
Now that I think of it, that won't work. The imap/pop3 processes kill themselves when they notice that the stderr pipe gets closed, so I can't think of a way for master to notify the imap/pop3 processes on-the-fly that they shouldn't die. Guess I'll add a setting instead.
Note: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173048
I'm firmly of the opinion that shutting down dovecot should shut down the child processes too - but the conf option is good as at least that way there's choice (the Unix way..).
If you're doing upgrades of critical applications at times when all your users are trying to use it *and* they aren't tolerant of a minor disruption then you're probably not really doing it at the right time...and dovecot's tolerant behaviour of this is covering up what would otherwise be regarded by most in terms of network management, as an example of poor judgement.
That's why there's "scheduled downtime" and "after hours" to do these things, in case stuff goes wrong, as some users of horde with dovecot have found out lately ;)
Reuben