Hi,
Not sure if this is relevant but having been running dovecot 1.1.4 for a long
time (without any problem) I recently upgraded to 1.1.7 when I switched to
SuSE 11.1 This is just running on my home server and it's a fairly standard
fetchmail-procmail-dovecot setup.
However I recently had an incident which I cannot quite explain. I suspect it
could be a possible disk problem but I did run a SMART check and the disks and
HW seems ok. The mail store is mounted on a separate partition using ext3 fs
What happened was that I noticed that the load on my server went through the
roof and that the imap process was hogging 100% of the CPU and it had been
running so for over an hour.
Before this happened I had just setup a new laptop with Thunderbird as the
mail client and had just done a off-line sync of my whole mail store (~1.5GB).
So for a short time the dovecot server would have been under maximum load.
I tried to recover by gracefully shutting down dovecot and when that didn't
stop the imap process I first tried to be nice by sending it the TERM signal
and when that didn't do it, the KILL signal.
However, I was not able to stop the imap process. I then decided to recycle
the server and initiated a shutdown. However, not even that was able to
complete (since the shutdown process seemed to be hanging on not being able to
stop the imap process). In the end I was (for the first time in over 6 years)
forced to use the hard reset button on the server.
I do realize that this is almost impossible to diagnose, but does anyone now
in general what could possible cause the imap process to so completely be
locked up that it is impossible to even shut it down?
The dovecot -n output is
1.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.27.7-9-pae i686 openSUSE 11.1 (i586) ext3
log_path: /var/log/dovecot.err
info_log_path: /var/log/dovecot.info
login_dir: /var/run/dovecot/login
login_executable: /usr/lib/dovecot/imap-login
login_processes_count: 2
login_max_processes_count: 2
login_max_connections: 5
max_mail_processes: 32
mail_max_userip_connections: 8
mail_location: maildir:/srv/mail/%u
mailbox_idle_check_interval: 15
fsync_disable: yes
auth default:
passdb:
driver: pam
userdb:
driver: passwd
Cheers
Johan
Johan Persson wrote:> the imap process was hogging 100% of the CPU and it had been > running so for over an hour.[...]> I tried to recover by gracefully shutting down dovecot and when that didn't > stop the imap process I first tried to be nice by sending it the TERM signal > and when that didn't do it, the KILL signal. > > However, I was not able to stop the imap process. I then decided to recycle > the server and initiated a shutdown. However, not even that was able to > complete (since the shutdown process seemed to be hanging on not being able to > stop the imap process).[...]> 1.1.7: /etc/dovecot/dovecot.conf > # OS: Linux 2.6.27.7-9-pae i686 openSUSE 11.1 (i586) ext3There was a thread on this list in December titled, "Dovecot imap processes pinning CPU," that talked about this. There's a bug in the linux kernel that creates unkillable, runaway processes when file monitoring is enabled. There's a patch[1], and it's supposedly fixed in 2.6.27.10. 1: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=711a49a07f84f914aac26a52143f6e7526571143