latest "news" on that: as woke up dbmail-imapd consumed all cores with 100% CPU however, from the users side it was still normally working so this affects not the whole daemon, only specific threads
after SIGKILL and restart it until now it did not happen again active (running) since Fr 2013-11-01 10:50:33 CET; 3h 6min ag very strange what it did not like last night Am 01.11.2013 04:15, schrieb Reindl Harald: > hmpf - again one thread with 100% > > is there a chance to get the coberity-fixes which where done > in HEAD also in the dbmail-3.1 tree - i have the strong feeling > there is a hidden bug and i can't setup the production machine > for debug-logging > > maybe some idiot out there is triggering this intentionally > > Am 01.11.2013 02:47, schrieb Reindl Harald: >> maybe one helpful information: >> >> on the production machine dbmail-imapd usually is not interested >> in SIGTERM and can only be killed with SIGKILL, indendent of the >> spin-locks, that's "normal" behavior here after some days production >> load >> >> Am 01.11.2013 02:42, schrieb Reindl Harald: >>> hm - the last few hours 5a9d6ba3645a235531ea32b2576fc21e2eb7b860 tries >>> repeatly to benchmark the production server with high CPU load >>> >>> * the service works normally and is responsible >>> * TLS not configured >>> * proxy in front >>> * nothing special in the maillog, no user load >>> * looks like the threads spinning around are growing >>> because it starts with 100% CPU up to 400% after >>> a few hours which means 4 cores are used >>> >>> i know that the informations are not helpful but i can't >>> reproduce this behavior and the build is running since >>> Oct 25 16:32:31, so i am confused
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
