Bug 173048 - dovecot should be also killing remaining pop3 and imap processes when exiting
dovecot should be also killing remaining pop3 and imap processes when exiting
Product: Fedora
Classification: Fedora
Component: dovecot (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Rockai
Depends On:
  Show dependency treegraph
Reported: 2005-11-12 20:39 EST by Reuben Farrelly
Modified: 2014-01-21 17:53 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-30 12:27:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Reuben Farrelly 2005-11-12 20:39:22 EST
At present when dovecot it shut down, the init script simply does this:

killproc /usr/sbin/dovecot

That of course kills the main dovecot processes and listeners, but does not kill
any child processes that were spawned by the dovecot master itself.  This means
that we are left with a whole lot of pop3 and imap sessions which are still open
on the server when it shuts down the network.  The end user impact is that the
users connections stay up until the lower TCP/IP layers figure out that the
server end has either gone away or torn down the connection.

To get around this we should really send a killall -TERM {imap|pop3} immediately
after killing the master dovecot process to ensure that the childs also die
somewhat gracefully.  When the childs are sent a TERM signal they notify the end
client like this:

Warning: Killed with signal 15
* BYE Server shutting down.

...which is much neater and additionally allows the server to shut down cleanly
without forcibly sending TERM and KILL signals to a whole heap of stray
disconnected processes.
Comment 1 Petr Rockai 2006-02-09 04:53:25 EST
"To get around this we should really send a killall -TERM {imap|pop3}    
immediately after killing the master dovecot process to ensure that the childs    
also die somewhat gracefully."    
No, no, absolutely not. This runs as root and kills anything named imap or    
pop3, which is a no-go. Imagine random user processes being named like that,    
dovecot restart would take them down. Or you run imap from dovecot and pop3    
from something else and the process names coincide. dovecot restart would have    
the interesting effect of killing all pop3 sessions on the other server. Etc.    
I would suggest asking upstream for the master to kill all mail processes upon   
exit, like it does with login and auth processes atm. Doing this in initscript   
is plain dangerous. 
Comment 2 Reuben Farrelly 2006-02-09 05:07:06 EST
Point taken. I sent an email to Timo (author) a few weeks ago suggesting it be
done by the master process, as I came to the conclusion after thinking that this
is probably something that should be done independent of Fedora/initscripts (ie
any dovecot installation on any platform would benefit from this.

Comment 3 Timo Sirainen 2006-02-10 10:38:17 EST
Well, I don't know if the imap/pop3 processes should be killed always. At least
in theory not doing that allows the existing imap/pop3 connections to stay
undisturbed while upgrading Dovecot.

Perhaps a configuration file setting, or maybe another signal could be used?
SIGINT maybe would kill the children also?
Comment 4 Reuben Farrelly 2006-02-11 04:04:39 EST
Yes at present during an upgrade the child processes stay hanging around.

But most of the time you *will* want the child processes killed:

1. If you're shutting down or going to init 1, you certainly will want them to
die gracefully preferably under dovecot's control
2. If you're doing an upgrade, then your users are probably expecting downtime
(or at least they should be), and most IMAP clients will reconnect anyway (in
the case of Thunderbird, silently reconnects, Outlook doesn't so silently do so)
3. If you're upgrading to fix a specific problem, then quite likely that problem
will be in the imap/pop3 processes rather than the master process or auth
processes.  It is not inconceivable that a client stays connected to the IMAP
server for days and days and never sees the upgrade till they reconnect later.

In a stable environment #1 would surely be the most common activity to be
happening.  In a test environment perhaps not so though.

POP3 is less of an issue, as pop3 sessions typically only last a short duration.
 It's only really IMAP sessions which can stay up and running (IDLE) for
variable and sometimes long periods of time that should be killed off.

I like the idea of a config option for killing or not killing the child
processes, with the default being to kill them (ie the default should be the
common case).  Testers can change that setting, of course ;-)

Comment 5 Petr Rockai 2006-02-15 09:33:35 EST
Reuben, Timo, i put this on NEEDINFO. When something is implemented upstream, 
can either you of you please flip this back to ASSIGNED to remind me it's  
my turn? I will try to not miss it either way, but sure is sure :).  
(Specifically important if i will have to twiddle initscripts). Thanks a lot.  
Comment 6 Reuben Farrelly 2006-04-12 07:51:51 EDT
This has been addresses in beta7.

+# 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

What are the chances of this hitting rawhide and picking up this and many other
bugfixes, Peter?

[Changing status to NEETINFO_ENG as there seems to be no ASSIGNED status anymore]
Comment 7 David Lawrence 2006-04-18 16:10:24 EDT
NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.
Comment 8 Petr Rockai 2006-05-30 12:19:47 EDT
Yes, beta8 will go to rawhide like tomorrow unless something unexpected 
happens. Sorry for the delay.
Comment 9 Petr Rockai 2006-05-30 12:27:33 EDT
Okey, you were asking for beta7 which is in for some time now, i just didn't 
realize that when writing comment #8. So if i understand this correctly, 
the issue is now fixed in rawhide. If i am wrong on some account, please 
reopen. (Nothing changes on the fact i'm pushing beta8 in a bit).

Note You need to log in before you can comment on or make changes to this bug.