Bug 6642

Summary: unknown facility/priority
Product: Spamassassin Reporter: Joan <jom>
Component: spamc/spamdAssignee: SpamAssassin Developer Mailing List <dev>
Status: RESOLVED WORKSFORME    
Severity: normal CC: apache, jom
Priority: P2    
Version: SVN Trunk (Latest Devel Version)   
Target Milestone: Undefined   
Hardware: PC   
OS: Linux   
Whiteboard:
Attachments: ruggedize syslog priority checking somewhat

Description Joan 2011-07-29 22:14:47 UTC
I have the following error message in my syslog :


2011-07-30T00:11:30+02:00 server spamd[838]: syslog: unknown facility/priority: 186a6
2011-07-30T00:11:30+02:00 server spamd[838]: syslog: unknown facility/priority: 186a6
2011-07-30T00:11:30+02:00 server spamd[838]: syslog: unknown facility/priority: 186a6


Using SVN

Thanks

JM
Comment 1 Mark Martinec 2011-07-29 22:42:00 UTC
> I have the following error message in my syslog :
> 2011-07-30T00:11:30+02:00 server spamd[838]: syslog: unknown facility/priority:
> 186a6
> Using SVN

Can this be reproduced at will? Are these frequent or just sporadic?
It would be useful to see the context, i.e. the surrounding debug messages
when full debugging is enabled.

Btw, I'm running the SVN trunk as well, but haven't see such log entries yet.
Comment 2 Joan 2011-07-29 22:55:25 UTC
it appears at each new message being checked.
Comment 3 Mark Martinec 2011-07-30 00:40:06 UTC
Created attachment 4943 [details]
ruggedize syslog priority checking somewhat

trunk:
  Bug 6642: unknown facility/priority - try to catch and report bad priority'
  Sending lib/Mail/SpamAssassin/Logger/Syslog.pm
Committed revision 1152404.

I don't see how that could be happening, but can't hurt to play safe.

Could you please try the attached patch (or just the updated SVN trunk)
and see if it makes any difference.
Comment 4 Joan 2011-08-08 09:03:04 UTC
Update to latest SVN.
Same message appears in the syslog
Comment 5 Joan 2011-08-26 02:33:59 UTC
Any news on this ?

Whatever SVN version gove the same syslog message.
Comment 6 Mark Martinec 2011-08-26 09:21:42 UTC
> Any news on this ?

No news. If you are still seeing this error despite the added safety net,
my guess is that the problem lies in your implementation or installation
of the perl module Sys::Syslog or something even below it.

What is the version of Sys::Syslog, which version of perl?
What OS? Was Sys::Syslog installed together of after the last
upgrade of perl, or is it older, compiled against an older perl?

Try:
# perl -le 'use Sys::Syslog; print Sys::Syslog->VERSION'
0.27
Comment 7 Joan 2011-08-26 13:27:53 UTC
# perl -le 'use Sys::Syslog; print Sys::Syslog->VERSION'
0.29
Comment 8 Joan 2011-08-26 13:28:28 UTC
# perl --version

This is perl 5, version 12, subversion 1 (v5.12.1) built for x86_64-linux-thread-multi
Comment 9 Joan 2011-08-26 13:29:38 UTC
OS = Linux 3.0.3, 64bits AMD

# uname -a
Linux server 3.0.3-server #2 SMP Thu Aug 18 17:03:01 CEST 2011 x86_64 GNU/Linux

libc 2.14
Comment 10 Joan 2011-08-26 13:31:17 UTC
I re-installed all Syslog moduels via cpan (using the force option)
Comment 11 Joan 2011-09-07 13:05:50 UTC
Any updates on this matter ?

I upgraded Perl to 5.14.1, rsyslog, etc... got the latest SVN, etc... still the same.
Comment 12 Mark Martinec 2011-09-08 00:49:42 UTC
> Any updates on this matter ?
> # perl -le 'use Sys::Syslog; print Sys::Syslog->VERSION'
> 0.29
> I upgraded Perl to 5.14.1, rsyslog, etc... got the latest SVN, etc...
> still the same.

So far it seems you are the only one experiencing this problem.
Troubleshooting it without being able to reproduce it is difficult.
I'm also running Perl 5.14.1 (*not* multithreaded) with Sys::Syslog 0.29,
and it works fine.

Did the self-test of a module Sys::Syslog run without errors?
Mine says:

# make test
PERL_DL_NONLAZY=1 /usr/local/bin/perl5.14.1 "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00-load.t .......... 1/1 # Testing Sys::Syslog 0.29, Perl 5.014001, /usr/local/bin/perl5.14.1
t/00-load.t .......... ok   
t/constants.t ........ ok     
t/data-validation.t .. skipped: POE is not available
t/distchk.t .......... ok   
t/pod.t .............. ok   
t/podcover.t ......... ok   
t/podspell.t ......... skipped: Pod spelling: for maintainer only
t/portfs.t ........... ok   
t/syslog.t ........... ok       
All tests successful.
Files=9, Tests=319,  1 wallclock secs ( 0.05 usr  0.06 sys +  0.65 cusr  0.15 csys =  0.91 CPU)
Result: PASS

The test sends log messages to a facility local0.
Check that these test log messages in a log file look alright.
You may need to adjust /etc/syslog.conf to see them.


Moreover, you may try experimenting with an option --syslog-socket
of spamd.  Its man page has this to say:


--syslog-socket=type

Specify how spamd should send messages to syslogd. The type can be
any of the socket types or logging mechanisms as accepted by the
subroutine Sys::Syslog::setlogsock(). Depending on a version of
Sys::Syslog and on the underlying operating system, one of the
following values (or their subset) can be used: "native",
"eventlog", "tcp", "udp", "inet", "unix", "stream", "pipe", or
"console".  The value "eventlog" is specific to Win32 events logger
and requires a perl module Win32::EventLog to be installed.  For
more information please consult the Sys::Syslog documentation.

A historical setting --syslog-socket=none is mapped to
-syslog=stderr.

A default for Windows platforms is "none", otherwise the default is
to try "unix" first, falling back to "inet" if perl detects errors
in its "unix" support.

Some platforms, or versions of perl, are shipped with old or
dysfunctional versions of the Sys::Syslog module which do not
support some socket types, so you may need to set this option
explicitly.  If you get error messages regarding __PATH_LOG or
similar spamd, try changing this setting.

The socket types "file" is used internally and should not be
specified.  Use the "-s" switch instead.
Comment 13 Mark Martinec 2011-09-14 09:54:08 UTC
trunk:
  Bug 6642: just in case - as a precaution against CPAN-RT#56826
  memory corruption bug in Sys-Syslog older than 0.28
Sending lib/Mail/SpamAssassin/Logger/Syslog.pm
Committed revision 1170502.

This is not directly related to Joan's case (but can't hurt to stay on
the safe side), as he is running an already fixed version Sys-Syslog 0.29
Comment 14 Henrik Krohns 2019-06-24 13:48:00 UTC
Closing stale bug.