This may be a silly question but how to correctly stop dovecot and be sure that it's possible to start it again?
kill -TERM cat /var/run/dovecot/master.pid doesn't work well.
I have imap-login processes staying arround and occupying port which leads to Fatal: listen(0.0.0.0, 993) failed: Address already in use when trying to start again 2s after stopping.
-- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/
At 23:42 +0200 25/7/08, Arkadiusz Miskiewicz wrote:
This may be a silly question but how to correctly stop dovecot and be sure that it's possible to start it again?
kill -TERM
cat /var/run/dovecot/master.piddoesn't work well.I have imap-login processes staying arround and occupying port which leads to Fatal: listen(0.0.0.0, 993) failed: Address already in use when trying to start again 2s after stopping.
The key is '2s after stopping'. It'll take longer than that for a port to be released the default 'tidyup' way. This happens with all sorts of services on all sorts of Unixy systems. Maybe it's the fault of the app not tidying up as it terminates, but it's far from uncommon.
David
-- David Ledger - Freelance Unix Sysadmin in the UK. HP-UX specialist of hpUG technical user group (www.hpug.org.uk) david.ledger@ivdcs.co.uk www.ivdcs.co.uk
Arkadiusz Miskiewicz wrote on Fri, 25 Jul 2008 23:42:09 +0200:
This may be a silly question but how to correctly stop dovecot and be sure that it's possible to start it again?
depends on your operating system. /etc/init.d/dovecot stop should work on most Linuxes.
I have imap-login processes staying arround and occupying port
Ah, well, that's a different question! Stopping dovecot won't kill the processes with actual logins. -> killall imap-login
Kai
-- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
On Jul 26, 2008, at 5:31 PM, Kai Schaetzl wrote:
I have imap-login processes staying arround and occupying port
Ah, well, that's a different question! Stopping dovecot won't kill the processes with actual logins. -> killall imap-login
It does kill everything. I don't know if there's anything that Dovecot
can do about the "Address already in use" problem. It seems that the
OS is keeping the listener alive for some reason longer than the
processes exist. I've had the exact same problem with some simple test
programs and haven't figured out how to avoid it (even cleanly closing
all the connections didn't help. although I just thought that perhaps
using shutdown() might have, guess I'll have to try the next time).
Maybe google would find something about this problem, I haven't looked.
On Saturday 26 July 2008, Timo Sirainen wrote:
On Jul 26, 2008, at 5:31 PM, Kai Schaetzl wrote:
I have imap-login processes staying arround and occupying port
Ah, well, that's a different question! Stopping dovecot won't kill the processes with actual logins. -> killall imap-login
It does kill everything.
"It" means what?
kill -TERM cat /var/run/dovecot/master.pid ? That doesn't kill imap-login
processes.
I don't know if there's anything that Dovecot can do about the "Address already in use" problem. It seems that the OS is keeping the listener alive for some reason longer than the processes exist.
imap-login processes still exist so this behaviour is valid.
I've checked few init.d/dovecot scripts and there is no imap-login killing in these, so I assumed that sending TERM to master causes master to kill it's childs but again - that's not the case here since dovecot process dies while imap-login is still alive.
-- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/
Arkadiusz Miskiewicz wrote:
On Saturday 26 July 2008, Timo Sirainen wrote:
On Jul 26, 2008, at 5:31 PM, Kai Schaetzl wrote:
I have imap-login processes staying arround and occupying port Ah, well, that's a different question! Stopping dovecot won't kill the processes with actual logins. -> killall imap-login It does kill everything.
"It" means what?
kill -TERM
cat /var/run/dovecot/master.pid? That doesn't kill imap-login processes.
What do you have for the "shutdown_clients" option?
I think the imap-login processes will hang around if there are SSL or proxy connections through them (but perhaps they shouldn't be "listen"-ing for new connections?).
Chris
-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
On Saturday 26 July 2008, Chris Wakelin wrote:
Arkadiusz Miskiewicz wrote:
On Saturday 26 July 2008, Timo Sirainen wrote:
On Jul 26, 2008, at 5:31 PM, Kai Schaetzl wrote:
I have imap-login processes staying arround and occupying port
Ah, well, that's a different question! Stopping dovecot won't kill the processes with actual logins. -> killall imap-login
It does kill everything.
"It" means what?
kill -TERM
cat /var/run/dovecot/master.pid? That doesn't kill imap-login processes.What do you have for the "shutdown_clients" option?
shutdown_clients: no
I think the imap-login processes will hang around if there are SSL or proxy connections through them (but perhaps they shouldn't be "listen"-ing for new connections?).
It would be good if existing clients were not disconnected but starting dovecot would be possible. That's how daemons for other services behave.
Chris
-- Arkadiusz Miśkiewicz PLD/Linux Team arekm / maven.pl http://ftp.pld-linux.org/
Arkadiusz Miskiewicz wrote:
What do you have for the "shutdown_clients" option?
shutdown_clients: no
I think the imap-login processes will hang around if there are SSL or proxy connections through them (but perhaps they shouldn't be "listen"-ing for new connections?).
It would be good if existing clients were not disconnected but starting dovecot would be possible. That's how daemons for other services behave.
It might be worth trying
login_process_per_connection = yes
That way, the login-processes have no need to be "listen"-ing once somebody has logged in.
Chris
-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
On Jul 26, 2008, at 10:05 PM, Arkadiusz Miskiewicz wrote:
I think the imap-login processes will hang around if there are SSL or proxy connections through them (but perhaps they shouldn't be "listen"-ing for new connections?).
It would be good if existing clients were not disconnected but
starting dovecot would be possible. That's how daemons for other services
behave.
This is how it should work, but for some reason netstat still shows
the process as listening even after closing the listener file
descriptors. I'll try to figure out later what the problem is. Perhaps
some stupid mistake that I'm not noticing now, or perhaps it has
something to do with the fd being opened by the master process and
transferred to a forked child process..
On Jul 26, 2008, at 8:29 PM, Timo Sirainen wrote:
On Jul 26, 2008, at 10:05 PM, Arkadiusz Miskiewicz wrote:
I think the imap-login processes will hang around if there are SSL
or proxy connections through them (but perhaps they shouldn't be "listen"-ing for new connections?).It would be good if existing clients were not disconnected but
starting dovecot would be possible. That's how daemons for other services
behave.This is how it should work, but for some reason netstat still shows
the process as listening even after closing the listener file
descriptors. I'll try to figure out later what the problem is.
Perhaps some stupid mistake that I'm not noticing now, or perhaps it
has something to do with the fd being opened by the master process
and transferred to a forked child process..
Timo Sirainen wrote on Sat, 26 Jul 2008 19:45:20 +0300:
It does kill everything.
Not for me, not with the 1.07 I have in CentOS 5.2. Look at the thread I started a few days ago with VA.000032de.0129b282@news.conactive.com
When I ran "service dovecot restart" (or stop) in that situation it did *not* kill all the pop3-login children. I had to use killall.
Kai
-- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
On Sun, 27 Jul 2008, Kai Schaetzl wrote:
It does kill everything. Not for me, not with the 1.07 I have in CentOS 5.2. When I ran "service dovecot restart" (or stop) in that situation it did *not* kill all the pop3-login children. I had to use killall.
It is normal for some services to terminate te main process, but leave active children alive. Especially for pop3 processes, as they can be considered to terminate soon due to protocol design. Same goes for ssh for example. You can kill (stop, or restart) the main sshd, without killing the sessions currently running. Exim also does similar things. Killing all children could result in data corruption, since seen flags etc. need to be saved before exiting.
The "restarting after 2 seconds" thing I just saw in another mail can possibly be prevented by using the appropriate setsockopts on the listen port (SO_REUSEADDR in this case, if I'm not mistaken). This may however very well be a Linux-specific solution.
Regards, Maarten Bezemer
Maarten Bezemer wrote on Sun, 27 Jul 2008 11:43:06 +0200 (CEST):
It is normal for some services to terminate te main process, but leave active children alive.
That may be so, but Timo claimed the opposite (as I read his response). I'm merely pointing out that I cannot see the behavior that Timo states. If you want to get rid of all these processes you have to killall.
Especially for pop3 processes, as they can be
considered to terminate soon due to protocol design.
Can you elaborate on this? Also, have a look at the thread I mentioned. Dozens pop3-login processes were staying sleeping for 5 or more hours. There was no remote part anymore. Doesn't sound like they "terminated soon due to protocol design".
Same goes for ssh for
example. You can kill (stop, or restart) the main sshd, without killing the sessions currently running.
Yes. Right you are. And especially with ssh it's quite helpful ;-)
The "restarting after 2 seconds" thing I just saw in another mail can possibly be prevented by using the appropriate setsockopts on the listen port (SO_REUSEADDR in this case, if I'm not mistaken). This may however very well be a Linux-specific solution.
That concerns the "tidying up"? In my case it wasn't a problem with still occupied ports, I checked for presence of processes.
Kai
-- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
On Sun, 2008-07-27 at 13:31 +0200, Kai Schaetzl wrote:
Maarten Bezemer wrote on Sun, 27 Jul 2008 11:43:06 +0200 (CEST):
It is normal for some services to terminate te main process, but leave active children alive.
That may be so, but Timo claimed the opposite (as I read his response). I'm merely pointing out that I cannot see the behavior that Timo states. If you want to get rid of all these processes you have to killall.
The behavior is controlled by shutdown_clients setting. I suppose you have it set to "no"?
Timo Sirainen wrote on Sun, 27 Jul 2008 17:14:29 +0300:
The behavior is controlled by shutdown_clients setting. I suppose you have it set to "no"?
It's set to how dovecot.conf came:
#shutdown_clients = yes
If that indicates the default it is enabled. But it didn't work. The thread I started wasn't so much about killing these children with a shutdown, anyway. It was about the behavior that these login processes stayed there for more than five hours after a dictionary attack that took only a few minutes before they eventually died away slowly.
Kai
-- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
participants (6)
-
Arkadiusz Miskiewicz
-
Chris Wakelin
-
David Ledger
-
Kai Schaetzl
-
Maarten Bezemer
-
Timo Sirainen