Jakub Suchy wrote:
i think you are right. strange is, that as mailq says, these two mails are not mailing list digests, but ordinary emails...
An example was sent to this list, it was a digest with 92 regular messages. Perhaps an ordinary message with a lot of sections (attachments, images, text and html) can produce the same effect.
If you wait long enough, like Nigel said, the message will be delivered and perhaps you can have access to it and see how it's contructed... that would be interesting.
it is also strange, that now i have only 2 "broken" mails, usually, after one appears, the whole mailq is undeliverable...
I think those 2 clamd threads will accumulate some messages while they process the problem ones, but other threads will continue work, slow under the overworked CPU but continue nonetheless.
do you know any debug options i can use to debug these 2 mails? log in clamd.log says nothing
No, my guess is that looking into the messages is the only fast way to have a clue. Other than that only attaching a debugger (gdb) to the clamd process and seeing where it is spending all that CPU time would be useful, but then you have to compile clamd with debug info (-g) and search on the threads to see which one has the problem message.
On practical terms, it may be worth trying the CVS version to see if this problem has been solved.
--
René Berber
_______________________________________________ http://lurker.clamav.net/list/clamav-users.html
