SA Bugzilla – Bug 4407
spamd error message every 5 minutes prefork: sysread(8) failed after 300 secs ...
Last modified: 2005-06-17 06:15:52 UTC
New install, running spamd on FreeBSD 5.4 produces error messages every 5 minutes. Seemd to run fine though. startup options: -c -d -u spamd -D -s /var/log/spamd.log -r /var/run/spamd.pid FreeBSD 5.4 Sendmail 8.13.3 See attached debug.
Created attachment 2943 [details] spamd debug output Deleted thousands of duplicate lines from file. Original file was 1.4M.
ok, this is actually fine. looking into it, this is what happens if the spamd receives no requests in 5 minutes. it's harmless. however, it is unattractive -- I'll come up with a patch...
Sending lib/Mail/SpamAssassin/SpamdForkScaling.pm Transmitting file data . Committed revision 191042. fixed.
Looks like the messages are gone, but running in debug mode, it looks like it now times out every 2 1/2 minutes instead of every 5 minutes. Normal? Oversight? Partial debug output: Fri Jun 17 10:14:08 2005 [6446] dbg: prefork: periodic ping from spamd parent Fri Jun 17 10:14:08 2005 [6446] dbg: prefork: sysread(8) not ready, wait max 300 secs Fri Jun 17 10:14:08 2005 [6447] dbg: prefork: periodic ping from spamd parent Fri Jun 17 10:14:08 2005 [6447] dbg: prefork: sysread(9) not ready, wait max 300 secs Fri Jun 17 10:16:39 2005 [6446] dbg: prefork: periodic ping from spamd parent Fri Jun 17 10:16:39 2005 [6446] dbg: prefork: sysread(8) not ready, wait max 300 secs Fri Jun 17 10:16:39 2005 [6447] dbg: prefork: periodic ping from spamd parent Fri Jun 17 10:16:39 2005 [6447] dbg: prefork: sysread(9) not ready, wait max 300 secs Fri Jun 17 10:19:10 2005 [6446] dbg: prefork: periodic ping from spamd parent Fri Jun 17 10:19:10 2005 [6446] dbg: prefork: sysread(8) not ready, wait max 300 secs Fri Jun 17 10:19:10 2005 [6447] dbg: prefork: periodic ping from spamd parent Fri Jun 17 10:19:10 2005 [6447] dbg: prefork: sysread(9) not ready, wait max 300 secs
normal -- if it was every 5 minutes, there'd be a race between the timeout code and the ping code, and sometimes the timeout may win... we could always make it longer if required, e.g. 4 mins 40 secs. but I don't see any problem that'll arise from either.