FYI, this just happened again a few minutes ago.
I do have a daily cron script that does restart dbmail daemons, even so
dbmail-imapd does crash
occasionally. (afaik only my and my wife's phone were even checking
mails atm)
On 2013-08-21 13:42, Thomas Raschbacher wrote:
On 2013-08-21 12:03, Paul J Stevens wrote:
On 21-08-13 10:48, Thomas Raschbacher wrote:
Hi.
I just had a problem as well where dbmail-imapd died on me.
Since It is just my server I did take a bit of time to create memory
dumps and core files
strace showed me this (again and again so some loop):
...
read(4, 0x1efbca0, 11) = -1 EAGAIN (Resource
temporarily unavailable)
write(13, "Q", 1) = -1 EAGAIN (Resource
temporarily unavailable)
...
i checked what fd 13 was and it is some sort of pipe
Correct. DBMail uses a self-pipe to signal the main thread that there
are jobs on the queue.
http://cr.yp.to/docs/selfpipe.html
This mechanism is mainly used by worker threads to tell the main
thread
they've finished with a workload.
It is also used by workers to send data to a client, through the main
thread. This is necessary because using libevent, basically we can't
do
network IO from threads other than the main thread.
Finally it is used to re-schedule a call-back if there is pending data
for the client, but writing to the client generated a soft-failure.
It is I suspect in this last scenario that the loop occurs. I've tried
very hard to make it full proof, but I'll add some more guards to
prevent this from happening.
ok i thought it was probably something thread related. thanks for the
explaination.
let me know if you need me to poke at the coredump or memory dumps. I
will keep them for now ;)
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
