Is there a graceful shutdown of imapd process?

[Dan Smith]

Thanks for your reply.  We're running Red Hat and just getting started with
Cyrus.
The solution is provided by a third party, so I'm kind of hobbled with what
I can and can't do (and have been told that patching imapd is definitely
out).

I thought a bit about the iptables solution, but it would still cause an
overall imap outage.  I was hoping that there would be a way to convince a
single imapd process to not take new connections...while allowing the others
to continue operating.  That would allow me to drain calls from one process
and restart it.  The connection duration wouldn't matter so much - as long
as it is scripted, I'd have all night.

My main goal is really to distribute newly created subscribers across
multiple partitions.  The vendor supports multiple messaging solutions, so
they chose to implement this partition load balancing as an external script
that updates the default partition and restarts imapd.  I have a strong
dislike for killing active connections, so I'm trying to find a better
solution.

I'm going to go back and beat on the vendor for a while to try to get them
to implement the partition load balancing in their creation request.

Thanks again!

-dan

-----Original Message-----
From: nodens2099 [mailto:nodens2099 at gmail.com] 
Sent: Friday, November 20, 2009 4:22 AM
To: Dan Smith
Cc: info-cyrus at lists.andrew.cmu.edu
Subject: Re: Is there a graceful shutdown of imapd process?

Le 19/11/2009 19:13, Dan Smith a écrit :
> My goal is to be able to reload the imapd.conf file for imap processes 
> without impacting currently connected subscribers.
> I know that there are some patches available to allow this to be done 
> with a SIGHUP, but until they are widely accepted and one is brought 
> into the code thread, we will probably shy away from it.
>  
> I was wondering if another approach would be possible.
> Is there any way that anyone can think of of that would stop an imapd 
> process from taking on new connections without impacting the existing
ones?
>  
> If there were, I could block new connections for one process at a time 
> and when all connections were drained off, restart it.
>  
> Any other ideas about how to accomplish this?
>  

Actually, the SIGHUP handling patch as been in debian packages (2.2.x) for a
while now. This is a pretty large audience, and AFAIK no problem has been
reported on this feature.

Anyway, if you are on linux (or *BSD), a good solution would be to prevent
new connections via netfilter/iptables (or pf for BSD), while allowing
"established" data flow, using the stateful firewalling.

The problem is, most modern clients try to stay connected...

Best regards,

--
Clément Hermann (nodens)