[Dovecot] How to upgrade a running Dovecot?

Mike Brudenell pmb1 at york.ac.uk
Fri Oct 5 12:25:49 EEST 2007


Hi, Jerry/et al -


On 4 Oct 2007, at 20:47, Jerry Yeager wrote:

> Have you considered sending out a message to each user to the  
> effect that on some day, darned-early a.m. the system will be  
> offline for 30 minutes for maintenance (no incoming email will be  
> lost, etc., etc.).

We have around 20,000 users at our site and need to keep downtime of  
the e-mail service to an absolute minimum.  The quietest time is at  
around 4:00am ... when I am sound asleep in bed, and plan to stay  
that way!  :-)

Seriously... I'm not new to timing and managing software upgrades:  
I've been doing it for around 19 years here now.

But what I _am_ new to is Dovecot.  Not knowing the software well  
yet, my questions are in an attempt to find the best way to flip it  
to a new configuration or version with minimal/no disruption to  
connected users.


>> Scenario 1:  Change to dovecot.conf
>> ===================================
>> If I make a change to dovecot.conf am I right in thinking I can
>> simply send a HUP signal to the main dovecot process to get it to re-
>> read the configuration file and act on its revised content?
>>
>
> Yes, this is correct.

Good...


>> Scenario 2:  Altered SSL Certificates
>> =====================================
>> I need to replace our current certificates and have prepared new
>> files containing the replacement certificate and private key.  Am I
>> right in thinking that I can simply modify dovecot.conf to point at
>> the new files and send a HUP signal to dovecot?  Specifically, will
>> new connections use the revised certificates, and existing
>> connections continue to work OK without interruption?
>
> Ehh not really, the auth child processes can be killed and new ones  
> started. See your next scenario question.

...So here you're saying that although the "dovecot" master process  
re-reads the configuration file, it doing so has no effect on the  
existing authenticator child processes?  And is it these processes  
that are dealing with the SSL connection? ... I'd have thought it was  
either the "imap-login" or "imap" processes?


>> Scenario 3:  Software Upgrade
>> =============================
>> I build a particular version of Dovecot into the tree /usr/local/
>> dovecot-A.B.C and then have a symlink called "dovecot" pointing at
>> the this directory.  To upgrade I can then build the new version
>> into /usr/local/dovecot-X.Y.Z and test.
>>
>> To actually switch over the live service to the new X.Y.Z version do
>> I need to:
>>
>>    a) Totally shut down the old A.B.C version of Dovecot, thereby
>> breaking all
>>       open connections for users?  or
>>
>>    b) Assuming I am using "shutdown_clients = no" can I just kill the
>> master
>>       "dovecot" process and then start up the new version?
>>
>
> See the preface, do the update when you typically have few folks  
> using the system -- which gives you fewer complaints from users  
> should things break on their end.

Yes... However the dovecot.conf configuration file includes a comment  
which says this:

# Should all IMAP and POP3 processes be killed when Dovecot master  
process
# shuts down. Setting this to "no" means that Dovecot can be upgraded  
without
# forcing existing client connections to close (although that could  
also be
# a problem if the upgrade is eg. because of a security fix). This  
however
# means that after master process has died, the client processes  
can't write
# to log files anymore.
#shutdown_clients = yes

This implies it *is* possible to upgrade the software without  
breaking existing live connections.  I'm trying to get confirmation  
of this along with any side-effects -- for example the comment seems  
to warn that pre-existing connections will no longer be able to write  
to the logfiles after the changeover?


Cheers,
Mike B-)

-- 
The Computing Service, University of York, Heslington, York Yo10 5DD, UK
Tel:+44-1904-433811  FAX:+44-1904-433740

* Unsolicited commercial e-mail is NOT welcome at this e-mail address. *




More information about the dovecot mailing list