i have spamassassin 2.55 app-admin/metalog-0.6-r10. default config on both. in /var/log/everything/current and /var/log/mail/current there are lines like: Aug 15 18:00:00 [CRON] (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons ) spamd[15085]: [info] setuid to rajiv succeeded spamd[15085]: [processing message <1ec101c36359$ff7c20f0$6401a8c0@satan> for rajiv] 501. spamd[15085]: [clean message (-4.6/5.0) for rajiv] 501 in 2.4 seconds, 7609 bytes. spamd entries in syslog are not prefixed with the date and time like other entries. Portage 2.0.48-r5 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1) ================================================================= System uname: 2.4.22_pre2-gss i686 AMD Athlon(TM) XP 2500+ GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /var/bind /usr/X11R6/lib/X11/xkb" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 oss 3dnow apm avi crypt cups encode foomaticdb gif imlib java jpeg libg++ libwww mad mmx mpeg ncurses oggvorbis pdflib png qt quicktime sdl slang spell svga truetype xml2 xmms xv zlib gdbm berkdb readline X tcpd pam ssl perl python gtk motif opengl ldap alsa apache2 cdr curl doc dvd emacs ethereal gtk2 imap innodb jikes maildir mbox mozilla mysql offensive sasl slp sse tcltk tiff usb xvid -arts -gpm -kde -gnome -mikmod -nls" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O3 -pipe" CXXFLAGS="-march=athlon-xp -O3 -pipe" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
i'm not sure where/how to start debugging this. anyone else see this?
Yo. I have the bug too. I tried looking at it before, but didn't get very far.
try spamassassin 2.6
updated to dev-perl/Mail-SpamAssassin-2.60-r1 ... still having this problem.
please try out metalog-0.8_pre20031130
i still get this problem even with metalog-0.8_pre20031130. I also get underscores (_) at the end of spamd log messages: spamd[15182]: [clean message (0.3/5.0) for root] 1002 in 15.7 seconds, 1944 bytes._ this happens for fetchmail log messages too. I have use metalog 0.7 - the underscore and spamd dates issues were present with that version aswell. However when i was using metalog 0.6 the underscore problem wasnt there.
metalog seems to have some weird ideas about log messages: It also puts everything before the first colon into square brackets. The posted log snippet would normally look like this: Aug 15 18:00:00 [CRON] (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons ) spamd[15085]: info: setuid to rajiv succeeded spamd[15085]: processing message <1ec101c36359$ff7c20f0$6401a8c0@satan> for rajiv:501. spamd[15085]: clean message (-4.6/5.0) for rajiv:501 in 2.4 seconds, 7609 bytes. I wasn't annoyed enough yet to find out how to tell metalog that that's nonsense.
This *might* be caused by spamd because it doesn't call openlog() but uses a direct call to syslog() instead. So the messages aren't prefixed. This is tracked as bug 3052 (see URL) in the SpamAssassin bug database. If this is really caused by spamd, it will be fixed for the next major release, which will be 3.0.
This is no SpamAssassin bug but is caused by the Sys::Syslog module. As both sysklog and syslog-ng work fine with this module, it is probably a bug in metalog. In the metalog sources there's a part where the input is parsed and which is marked as a kludge; I guess that's the culplrit but didn't have the time to track it further down.
I'm not sure this is a bug so much as a "feature" of Sys::Syslog. Sys::Syslog was originally written to interface with Unix style syslog's - which are generically similar to sysklog and syslog-ng, and nothing like metalog with its "write intermittently features" (I don't use metalog, not a big fan, so that last bit was unwarrantedly biased). SpamAssassin could use a different method of writing to the system logs or could offer choices based on your syslog utility of choice, but either way this really isn't a bug with gentoo. Gentoo's options as I understand them are to either block users of metalog from using SpamAssassin (NO, BAD), or to accept this and contact the SA folks to let them know of the potential problem (which if I read the comments correctly has already been done to some degree).
I am one of the "SA folks" :) I use metalog myself because it was once recommended in the install guide and I looked for something more flexible than sysklog; but I'll probably switch to syslog-ng soonish. We will probably just mark this as a "known issue" in the README and good is. As I said before, this is probably not a Sys::Syslog bug. It just writes to the syslog socket in something which looks like some syslog formatted message. metalog then obviously fails to identify this format, maybe thinking it already has a date prepended or something. Somebody might want to forward this to the metalog folks, but I don't think it will help much as it seems like metalog is unmaintained and almost dead for at least half a year now. (I am not even sure if I hadn't seen a bug report about this in their tracker.) Short conclusion: metalog is broken and dead. As long as some hardcore metalog fan doesn't fix it, it will probably stay in this state forever.
Why do so many of my posts lately involve removing my foot from my mouth (sorry Malte :) ). Rajiv - I think this bug should probably be closed as CANTFIX. (Read above posts)
Michael, no problem, I think my previous postings weren't written in a very clear and understandable manner :)
re comment 11: i also use metalog because the install guide recommended it. the guide has since been updated to recommend syslog-ng. closing as UPSTREAM. SA folks can either fix the interaction between SA and metalog, or just add a 'known issue' to the spamassassin BUGS file. see http://bugzilla.spamassassin.org/show_bug.cgi?id=3052 for additional info. thanks