On Fri, 2004-03-05 at 01:15, Doug Hardie wrote: > > > > I just uncommented the thread timeout the last time I restarted clamd > > a couple minutes ago so I don't know what effect that will have.
ThreadTimeout isn't used in the current CVS version. > Here is some more information: After running with the timeout set to > 500, clamd no longer dies. It chugs along for quite awhile (about 10 > minutes) at full cpu usage and then returns to normal use. I don't see > anything different in the load between the periods. However a ktrace > of clamd shows a significant difference. Normally clamd shows nothing > much when idle and it shows the messages being received (read) when > processing a message. However, when its running at full cpu > utilization, ktrace shows thousands of sequences like: > > 8313 clamd PSIG SIGPROF caught handler=0x28116228 mask=0x0 > code=0x0 > 8313 clamd CALL gettimeofday(0x2815fe4c,0) > 8313 clamd RET gettimeofday 0 > 8313 clamd CALL sigprocmask(0x3,0x2815fed8,0) > 8313 clamd RET sigprocmask 0 > 8313 clamd CALL sigaltstack(0x2817c000,0) > 8313 clamd RET sigaltstack 0 > 8313 clamd CALL poll(0x806f000,0x1,0) > 8313 clamd RET poll 0 > 8313 clamd CALL sigreturn(0x808ac64) > 8313 clamd RET sigreturn JUSTRETURN > > and then there will be one message processed and then back to a few > more thousand of those sequences. This looks entirely broken. Your trace indicates that the last argument to poll (the timeout) is zero. The code looked like this count = poll(poll_data, 1, CL_DEFAULT_SCANTIMEOUT*1000); i.e. the timeout *can't* be zero unless you changed the value of CL_DEFAULT_SCANTIMEOUT or your system is fundamentally broken. unless your system is using poll to spin somewhere. -trog
signature.asc
Description: This is a digitally signed message part
