[Dovecot] Crash in 2.0.8 dovecot/imap - information capture
My dovecot logs revealed a crash in the dovecot/imap process a few days ago. It appears to have dereferenced 0x00000004 in the storage shared lib. Unfortunately, I didn't get a core and I'm not sure how to reproduce it. Dovecot 2.0.8 on linux32.
Two questions:
How can I be sure I get a core next time? I think it's because I run dovecot/imap under a mail uid and didn't have write permission to the cwd. Any way to verify that was it, and be sure it works?
What other settings would provide more info if it happens again?
Thanks!
dovecot.log excerpt: Dec 10 08:43:53 master: Error: service(imap): child 30862 killed with signal 11 (core dumps disabled) Dec 10 08:43:53 imap-login: Info: Login: user=xx@yy.com, method=PLAIN, rip=169.254.100.10, lip=169.254.100.100, mpid=2243
kernel dmesg: imap[30862]: segfault at 4 ip b772ecd2 sp bfc90f90 error 4 in libdovecot-storage.so.0.0.0[b76e9000+b8000]
[~] # dovecot -n # 2.0.8: /etc/dovecot/dovecot.conf # OS: Linux 2.6.33.2 i686 ext4 (not sure of exact config at time of crash, will capture next)
On Sun, 2010-12-12 at 10:51 -0500, Tom Talpey wrote:
- How can I be sure I get a core next time? I think it's because I run dovecot/imap under a mail uid and didn't have write permission to the cwd. Any way to verify that was it, and be sure it works?
http://dovecot.org/bugreport.html explains all of the things you need to get core dumps. Although some of those settings are v1.x specific, so I should look into updating the page..
Anyway, you can also test that you really get core dumps by manually sending a SEGV signal to one test imap process.
- What other settings would provide more info if it happens again?
The gdb backtrace will be enough.
Dec 10 08:43:53 master: Error: service(imap): child 30862 killed with signal 11 (core dumps disabled)
Run "ulimit -c unlimited" before starting dovecot.
participants (2)
-
Timo Sirainen
-
Tom Talpey