On Thu, Dec 11, 2008 at 7:49 AM, Allan Cassaro <allan.cass...@gmail.com> wrote: > On Thu, Dec 11, 2008 at 7:17 AM, Steffen Kaiser > <skdove...@smail.inf.fh-brs.de> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On Thu, 11 Dec 2008, Allan Cassaro wrote: >> >> On Thu, 11 Dec 2008, Allan Cassaro wrote: >> >>> I donĀ“t have SELinux, or any type or hardening... The ulimit (when >>> logged with dovecot user) is "unlimited"... >> >> Yes, but when Dovecot is spawned as service, the user dovecot does not log >> in (through PAM anyway to have pam_limits invoked), therefore I assume >> that limits.conf does not take effect. >> >>> Dovecot ran with a lot of proccess here, something about 800~900 imap >>> proccess and 5~10 login-proccess to 300~400 simultaneous users... >> >> Hmm, I do remember something similiar when the new students arrived and >> the number of simultaneous logins increased above some limit. >> I added the ulimit command to init.d. > > After our conversation, I made some tests: > 1) Adding this line to /etc/pam.d/common-session (Debian system) > > session required pam_limits.so > > # cat /etc/security/limits.conf > dovecot hard nofile 2048 > dovecot soft nofile 2048 > > The limits.conf is respected now. > # su -c 'ulimit -n' dovecot > 2048 (The value of limits.conf) > (no login) > > # /etc/init.d/dovecot restart > Warning: fd limit 1024 is lower than what Dovecot can use under full > load (more than 1456). Either grow the limit or change > login_max_processes_count and max_mail_processes settings > > (Problem persists) > > 2) Change the ulimit for root user (as you saw): > # ulimit -n 2048 > > # /etc/init.d/dovecot restart > (no errors) > > # cat /etc/security/limits.conf > dovecot hard nofile 2048 > dovecot soft nofile 2048 > root hard nofile 2048 > root soft nofile 2048 > > So, I think that dovecot uses the limit from the "root" user, not dovecot... > Now I will wait 20 minutes and see what happens :D > > Hooo.. another (ugly) think: > When imap crashes, the antispam plugin don't erase the > /tmp/antispam-plugin-XXXXX dir (obviously). So this is possibly to > "delay" or avoid creation of temp dirs? >
Hi Steffen, after some others tests, I don't have problem with file descriptors any more, but the plugin make the imap proccess dies with segfault yet... How can I help more to find this issue? Regards.