On Wed, Dec 17, 2008 at 4:45 PM, Allan Cassaro <allan.cass...@gmail.com> wrote: > 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.
Now, I compiled with "debug" enabled and I can saw (a lot of) this on syslog: Dec 18 10:30:13 curie imap: antispam: plugin initialising (1.1-notgit) Dec 18 10:30:13 curie imap: antispam: no trash folders Dec 18 10:30:13 curie imap: antispam: "Bloqueados" is spam folder Dec 18 10:30:13 curie imap: antispam: no unsure folders Dec 18 10:30:13 curie imap: antispam: mail backend spam address -a Dec 18 10:30:13 curie imap: antispam: mail backend not-spam address -d Dec 18 10:30:13 curie imap: antispam: mail backend sendmail /usr/libexec/dovecot/blockthis.py Dec 18 10:30:13 curie imap: antispam: mail backend sendmail arg -u Dec 18 10:30:13 curie imap: antispam: mail backend sendmail arg abuarque Dec 18 10:30:13 curie imap: antispam: mail backend tmpdir /tmp Dec 18 10:30:13 curie dovecot: child 29672 (imap) killed with signal 11 Regards.
