Bug 6007 - spamd always logs to stderr, regardless of "-s" switch
Summary: spamd always logs to stderr, regardless of "-s" switch
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: unspecified
Hardware: Other All
: P5 enhancement
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-28 08:29 UTC by Justin Mason
Modified: 2008-11-03 01:14 UTC (History)
1 user (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Mason 2008-10-28 08:29:17 UTC
http://jwz.livejournal.com/954898.html :

'Dear Lazyweb, I'm trying to get the postfix, dovecot, and spamd logs out of
/var/log/system.log and into their own files on MacOS 10.5.5. [...] The result:
postfix and dovecot are logged into mail.log and not into system.log. Good.
Spamd is logged into spamd.log. Good. But spamd is also logged into
console.log. Bad. And I don't understand why.



I went a looked up the docs, there's a "--syslog" command line option to specify which facility the log messages go to. I wonder if somehow spamd is getting run with this command line switch and also a similiar command in the config file, causing it to log to both places.

The other thing I see is this:

spamd -s stderr 2>/dev/null # log to stderr, throw messages away

Do you think spamd is logging to syslog, AND also sending messages to stderr? The syslog messages will go to the mail log, but the stderr messages might go to the console, hence ending up in console.log and maybe the syslog as well.

You can try starting spamd with stderr piped to /dev/null as suggested above. It might work. Other than that, though, I got nothin'....



That was it! Apparently spamd unconditionally writes all its messages to stderr as well, regardless of what the -s option says. Adding

    <key>StandardErrorPath</key>
    <string>/dev/null</string> 

to /Library/LaunchDaemons/org.macports.spamd.plist seems to have fixed it. Thanks!



I'm not sure what version of SpamAssassin you're using, but I just grabbed the .tgz for 3.2.5, and I found this in Mail-SpamAssassin-3.2.5/lib/Mail/SpamAssassin/Logger.pm (line 69):

# always log to stderr initially
use Mail::SpamAssassin::Logger::Stderr;
$LOG_SA{method}->{stderr} = Mail::SpamAssassin::Logger::Stderr->new();

I suspect if you comment out that last line, it'll never log to stderr. The $LOG_SA hash contains the facilities and other stuff. Commenting out that line will be easier than going into log_message() sub (line 133) and hacking in some kind of special case to the while(each($LOG_SA{method})){ log_message($msg); } loop (line 165).

(I'm too lazy to enter this as a bug in the SpamAssassin bug tracker, but if someone else wants to, have at it.)'