On 23-08-13 00:06, Chedomir Nikolikj wrote: > Well the service is not running, so imap connection's cannot be > established, if that's the question
So it crashed. That was the question. Not in a spin-lock then. > We are running dbmail as a daemon, starting it as regular service from > /etc/init.d/dbmail-imapd Ok. Well, the logs do show one small thing that shouldn't happen. Writing to client fails with a 'Broken pipe' error, so dbmail schedules a session shutdown: shuts down the client connection and cleans up the session. Apparently somewhere along the way either a SIGABRT is triggered by an assert, or a SIGSEGV is triggered by programming error. Segfaults are usually 'annotated' in the syslogs by glibc's guards. In this case however, I notice that the client-state switches: 4 -> 6 (LOGOUT -> ERROR) after the 'Broken pipe'. Ok. 6 -> 7 (ERROR -> QUIT_QUEUED) so a cleanup is scheduled. Still ok, but then: 7 -> 6 (QUIT_QUEUED -> ERROR) this shouldn't happen, because then 6 -> 7 (ERROR -> QUIT_QUEUED) a second cleanup is scheduled. I suspect that this second round of a scheduled cleanup triggers an assert in the code leading to a SIGABRT. > Also we use a custom authldap.c so we can authenticate with custom > attribute for ldap password authentication. Maybe that has something to > do with this issue ? I seriously doubt it. That would result in totally different log-lines. Please try to re-base against dbmail_3_1, or apply http://git.dbmail.eu/paul/dbmail/patch/?id=33f941645113bebb0014871e9431858b0876f246 -- ________________________________________________________________ Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin * Premium Hosting Services and Web Application Consultancy * www.nfg.nl/[email protected]/+31.85.877.99.97 ________________________________________________________________ _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
