Re: [Dovecot] Segfault on antispam plugin
On Thu, Dec 11, 2008 at 7:49 AM, Allan Cassaro allan.cassaro@gmail.com wrote:
On Thu, Dec 11, 2008 at 7:17 AM, Steffen Kaiser skdovecot@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:
- 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)
- 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.
On Wed, Dec 17, 2008 at 4:45 PM, Allan Cassaro allan.cassaro@gmail.com wrote:
On Thu, Dec 11, 2008 at 7:49 AM, Allan Cassaro allan.cassaro@gmail.com wrote:
On Thu, Dec 11, 2008 at 7:17 AM, Steffen Kaiser skdovecot@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:
- 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)
- 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 18 Dec 2008, Allan Cassaro wrote:
BTW: Without a trash folder configured, deleting a mail from the SPAM folder will cause a HAM learning.
Dec 18 10:30:13 curie imap: antispam: mail backend sendmail /usr/libexec/dovecot/blockthis.py
Hmm, antispam uses exec() to execute the binary. I'm not sure whether or not the kernel supports shell scripts here. I suggest to use the interpreter python as binary and the script as argument.
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
With that I cannot really help you. Usually I try to put some debug() statements in there to check, how far the process runs before it dies, in order to narrow down the point in the source. However, I'm not the developer of this plugin and I cannot help you debugging stack traces or core dumps.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJSkl4VJMDrex4hCIRAhA/AJ4l1PefoHn5Evw7HTQO9pUQlrHDAQCgvXwV wOgsJ5QZECS7oTp9T86A5QE= =ZBV3 -----END PGP SIGNATURE-----
On Thu, Dec 18, 2008 at 11:00 AM, Steffen Kaiser skdovecot@smail.inf.fh-brs.de wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 18 Dec 2008, Allan Cassaro wrote:
BTW: Without a trash folder configured, deleting a mail from the SPAM folder will cause a HAM learning.
Yes! This is exactly what I want! :D If the user put some e-mail on "Blocked" folder, the python script extract the "From" and modify the sieve of this user and insert a "fileinto Trash".
If the user exclude (or move to another folder) the script remove the "fileinto" rule.
Works wonderful! My users really like it! :D
Dec 18 10:30:13 curie imap: antispam: mail backend sendmail /usr/libexec/dovecot/blockthis.py
Hmm, antispam uses exec() to execute the binary. I'm not sure whether or not the kernel supports shell scripts here. I suggest to use the interpreter python as binary and the script as argument.
Well , this error don't occurs all the time. Is very intermittent. I don't believe that this is the problem... But I can test...
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
With that I cannot really help you. Usually I try to put some debug() statements in there to check, how far the process runs before it dies, in order to narrow down the point in the source. However, I'm not the developer of this plugin and I cannot help you debugging stack traces or core dumps.
Humm... this is bad... :( But if I can help you to help me with anything...
Regards.
participants (2)
-
Allan Cassaro
-
Steffen Kaiser