[Dovecot] Segfault on antispam plugin

[Allan Cassaro]

On Wed, Dec 17, 2008 at 4:45 PM, Allan Cassaro <allan.cassaro at gmail.com> wrote:
> On Thu, Dec 11, 2008 at 7:49 AM, Allan Cassaro <allan.cassaro at gmail.com> wrote:
>> On Thu, Dec 11, 2008 at 7:17 AM, Steffen Kaiser
>> <skdovecot at 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.