http://bugzilla.spamassassin.org/show_bug.cgi?id=2923
Summary: Locking problem in UnixLocker.pm (FIX INCLUDED!)
Product: Spamassassin
Version: 2.61
Platform: PC
URL: http://infohost.nmt.edu/~wcolburn/UnixLocker.pm
OS/Version: Linux
Status: NEW
Severity: major
Priority: P4
Component: spamassassin
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I have a FIX for this bug (see URL and below).
I was made to to use spamassassin by my boss. My mail server went from a nice
<1 load average to a load of about 10 most of the time, with spikes up to 200 no
more than every other day. As time wore on I got more and more tired of being
paged in to work because the mail server was locked up. The cron job to kill
spamd processes which had been running more than one minute wasn't able to keep
up. I managed to get things under control by removing -a from the command line
to spamd. A quick look showed that all the CPU-destroying spamd processes
seemed to be trying to lock the auto-whitelist file.
I don't know perl. I have feared and shunned it all my life because it is the
burning and smoking semen straight of the loins of the devil himself. I'm not
entirely sure what that lock routine was supposed to do, but I'm very sure it
wasn't correct. I wrote a new one,
http://infohost.nmt.edu/~wcolburn/UnixLocker.pm and that helped me immensely. I
must give many thanks to the O'Reilly perl book and its glorious index which
helped me translate a real programming language into perl.
It has all but cleared up my problems. Once since rewriting the locking
function I have had a hang writing the auto-whitelist file. An strace showed
that no system calls were being made, and gdb said it was in gdbm_store(). I am
hoping the file was merely corrupt from an improperly broken lock. Without -a,
my load goes back to <1. With -a and my locking routine it lingers around 1.
With -a and your locking routine it lingers around 5 during slow mail hours, and
about 12 to 15 during normal mail hours, and hasn't peaked much higher than 200
when very busy. Overall, I think I have a winner.
Here is a trace of the hang from gdb, in case you care:
#0 0x4048ca74 in gdbm_store () from /usr/lib/libgdbm.so.2
#1 0x4048240b in XS_GDBM_File_STORE (my_perl=0x804bcb8, cv=0x8a80a20)
at GDBM_File.c:344
#2 0x400a34e5 in Perl_pp_entersub (my_perl=0x804bcb8) at pp_hot.c:2781
#3 0x40086c9a in Perl_runops_debug (my_perl=0x804bcb8) at dump.c:1414
#4 0x4003b759 in S_call_body (my_perl=0x804bcb8, myop=0xbfffde00, is_eval=0)
at perl.c:2069
#5 0x4003b617 in Perl_call_sv (my_perl=0x804bcb8, sv=0x804bcb8, flags=66)
at perl.c:1948
#6 0x4003ade6 in Perl_call_method (my_perl=0x804bcb8, methname=0x0, flags=66)
at perl.c:1881
#7 0x4008f5bc in S_magic_methcall (my_perl=0x42, sv=0x0, mg=0x96b7128,
meth=0x0, flags=0, n=3, val=0x0) at mg.c:1328
#8 0x4008fa32 in Perl_magic_setpack (my_perl=0x804bcb8, sv=0x9686150, mg=0x0)
at mg.c:1365
#9 0x4008d429 in Perl_mg_set (my_perl=0x804bcb8, sv=0x9686150) at mg.c:184
#10 0x4009b831 in Perl_pp_sassign (my_perl=0x804bcb8) at pp_hot.c:111
#11 0x40086c9a in Perl_runops_debug (my_perl=0x804bcb8) at dump.c:1414
#12 0x4003a9ab in S_run_body (my_perl=0x804bcb8, oldscope=0) at perl.c:1705
#13 0x4003a635 in perl_run (my_perl=0x804bcb8) at perl.c:1624
#14 0x080493a3 in main ()
#15 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
I will try to attach my patch as suggested, but if I fail, I have gien the URL
for a copy of it twice now. :)
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
