http://bugzilla.spamassassin.org/show_bug.cgi?id=3828
------- Additional Comments From [EMAIL PROTECTED] 2004-11-10 11:26 -------
well.. i've been hearing and seeing a few reports of spamd still getting looped
up even when running with --timeout-tcp and --timeout-child. just today i
caught one,
1042 minutes on one child, 11 minutes on another...
1:05pm up 30 days, 4:42, 1 user, load average: 4.28, 3.56, 3.35
134 processes: 126 sleeping, 6 running, 2 zombie, 0 stopped
CPU states: 98.5% user, 1.4% system, 0.0% nice, 0.0% idle
Mem: 253876K av, 206464K used, 47412K free, 0K shrd, 12868K buff
Swap: 522104K av, 221484K used, 300620K free 33372K cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
7730 root 19 0 27544 32 4 R 45.1 0.0 1042m spamd
8490 root 19 0 25612 24 4 R 44.4 0.0 11:22 spamd
19905 root 20 0 26352 19M 1480 R 4.4 7.8 0:05 spamd
20512 qmailq 20 0 1924 1924 1148 R 1.4 0.7 0:00 perl5.6.1
20454 root 10 0 1116 1116 848 R 0.2 0.4 0:00 top
1 root 8 0 112 64 48 S 0.0 0.0 0:05 init
that tells me that it must be looping inside another eval{} somewhere...
otherwise the --timeout-child would kick in. I'll ask, before I go hunting...
is there any eval'd code that is not alarmed? razor, pyzor, dcc, rbl, uribl,
etc?
unfortunately i wasnt able to gather much information on this one since i didnt
have debug turned on. this is the second time in as many days that this box has
done this. i thought it might have been bayes expiry, so i disabled bayes
yesterday and the problem came back... so i have ruled out bayes (specifically
auto-expiry and learning) for now and will debug further and hope the problem
comes back tommorrow (as bad as that sounds :)
d
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
