The stock syslog.conf on OSX contains in part:
*.notice;authpriv,remoteauth,ftp,install.none;kern.debug;mail.crit /var/log/system.log
mail.* /var/log/mail.log
I tried changing that to:
*.notice;authpriv,remoteauth,ftp,install,mail,local7.none;kern.debug /var/log/system.log
mail.* /var/log/mail.log
local7.* /var/log/spamd.log
And launching spamd with "-s local7".
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.
Also, messages from spamd are logged slightly differently in the two files. Dunno if that's relevant, but the logs look like:
system.log:
Oct 26 19:01:55 grendel org.macports.spamd[39735]: [39736] info: prefork: child states: II
versus spamd.log:
Oct 26 19:01:55 grendel spamd[39736]: prefork: child states: II
So how do I keep spamd out of system.log?
Update: The answer is, "redirect spamd's stderr to /dev/null or launchd will log it a second time." Apparently spamd spams stderr with all its logs as well as whatever the -s option says.
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
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.)
doh.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6007