Gang,
I may have stumbled on a solution to the "too many open files" issue, but I am wondering about the security consequences. I changed login_process_per_connection from "yes" to "no". This makes a HUGE reduction in the number of imap-login processes, from ~200 down to the login_processes_count (currently the default of 3). It also made my "too many open files" syslog complaints vanish. Yippee!
But is there any serious security risk of login_process_per_connection=no?
Jeff Earickson Colby College
On Wed, 6 Sep 2006, Chris Wakelin wrote:
Date: Wed, 06 Sep 2006 01:12:34 +0100 From: Chris Wakelin c.d.wakelin@reading.ac.uk To: Jeff A. Earickson jaearick@colby.edu Cc: dovecot@dovecot.org Subject: Re: [Dovecot] rc7 crashing under heavy load
Too many open files - try increasing the number of file handles for the Dovecot master process; I use "plimit -n 4096 <Dovecot master pid>"
A plimit on my dovecot master process shows:
plimit 25773 25773: /opt/dovecot/sbin/dovecot resource current maximum time(seconds) unlimited unlimited file(blocks) unlimited unlimited data(kbytes) unlimited unlimited stack(kbytes) 8192 unlimited coredump(blocks) unlimited unlimited nofiles(descriptors) 65536 131072 vmemory(kbytes) unlimited unlimited
The number of file descriptors comes from my kernel tweaks in /etc/system.
Login process died too early - are you using NIS? It's too slow for Dovecot, I think. We create a Dovecot "passwd-file" from NIS overnight and then "HUP" the Dovecot master process to make it re-read it (we use it only for UIDs, as we use pam-ldap to Active Directory for authentication, but it could have the passwords in as well). Dovecot caches the passwd-file so it's very quick.
No, but I was using automounter and LOFS (loopback file systems) in a big way on my imap server to access user homedirs. It was elegant from a sysadmin point of view, but a latency issue for dovecot with all of the waiting for homedirs to automount. I scrapped that last night and it helped.