[Dovecot] Upgrading a live running dovecot - how?
Hi Guys,
This has bitten us twice now. We're running Gentoo and emerge (ie compile) a new version of Dovecot thinking we can finish that then restart Dovecot in our own time.
It seems that Dovecot immediately starts to use the newly compiled Dovecot binary and we get version mismatch errors preventing access.
Would be good if Dovecot behaved in such a way that it kept on using the old version (held in memory) until it was restarted where it then loaded the new version.
Dan
Daniel Watts wrote:
Hi Guys,
This has bitten us twice now. We're running Gentoo and emerge (ie compile) a new version of Dovecot thinking we can finish that then restart Dovecot in our own time.
It seems that Dovecot immediately starts to use the newly compiled Dovecot binary and we get version mismatch errors preventing access.
Would be good if Dovecot behaved in such a way that it kept on using the old version (held in memory) until it was restarted where it then loaded the new version.
I think if you read the section on pre-init scripts you can see that the way dovecot works is something like to keep long term auth processes, but to fork a new server process for each user. So I guess each login will instantly see the new binary...
Perhaps you could build a binary package, then in some slightly quiet time you could install the package and slip a "/etc/init.d/dovecot restart" on the end? I *think* that the way the restart works is to keep existing clients alive until they quit (it's an option in the conf file though?)
I'm out of my depth to be honest, but you didn't get an answer, so perhaps that helps a little..?
Ed
On Sun, 2008-01-06 at 01:05 +0000, Ed W wrote:
Daniel Watts wrote:
Hi Guys,
This has bitten us twice now. We're running Gentoo and emerge (ie compile) a new version of Dovecot thinking we can finish that then restart Dovecot in our own time.
It seems that Dovecot immediately starts to use the newly compiled Dovecot binary and we get version mismatch errors preventing access.
Would be good if Dovecot behaved in such a way that it kept on using the old version (held in memory) until it was restarted where it then loaded the new version.
I think if you read the section on pre-init scripts you can see that the way dovecot works is something like to keep long term auth processes, but to fork a new server process for each user. So I guess each login will instantly see the new binary...
This is correct. I can't really think of any reasonable way to keep using old binaries. But it is possible to use version_ignore=yes and it'll most likely work just fine.
Although I had been thinking about using some kind of imap-forker processes for improving performance. So that you'd have one permanent imap process that has already initialized itself by loading all plugins and such. It would be waiting for new (post-login) connections, and when it sees one it just forks itself to handle it.
That won't anyway happen before v2.0, and I'm not sure if it's even then a good idea. It has some potential security issues .. like you have to be careful to reseed the random number generators for all new connections. Also if address space layout randomization is used, it's the same for all imap processes which isn't very good.
participants (3)
-
Daniel Watts
-
Ed W
-
Timo Sirainen