On 8/20/2011 12:47 AM, Russ Allbery wrote:
Jeremy Maryott<j...@hampshire.edu> writes:
Package: libapache2-mod-shib2
Version: 2.3.1+dfsg-5
Severity: normal
In /etc/shibboleth/native.logger, there are some Debian-specific config
lines, one of which is:
log4j.appender.native_log.facility=24
24 is not a valid facility, and causes problems with rsyslog (messages
show up with 'invld' in them). More specifically, the logs showed up
fine on the server this package is installed on, but I ran into problems
forwarding the logs to a Debian 5 server.
Switching to a facility of 3 and restarting apache fixed this problem.
As the comment says, that's LOG_DAEMON:
# Use syslog instead, since then at least the messages will go somewhere.
# That facility is (3<< 3) or LOG_DAEMON, since log4cpp apparently
# doesn't recognize symbolic log facilities.
See /usr/include/sys/syslog.h:
#define LOG_DAEMON (3<<3) /* system daemons */
I tried with a facility of 3 before and it didn't work. Could this be
different when forwarding the logs rather than logging it locally? Or
maybe rsyslog itself is different? I had originally tested with sysklogd,
and I seem to recall at the time I checked log4cpp's source code and this
looked like it would do the right thing.
I can try again... it's also possible that log4cpp has changed.
Although the problem with weird long lines only showed up when I was logging
remotely, local rsyslog also thinks the facility is bad; it looks like it just
handles it better. If I log with a template like: "%timegenerated% %PRI-text%:
%syslogfacility% %syslogpriority% %HOSTNAME% %syslogtag%%msg:::drop-last-lf%\n"
then %syslogfacility% becomes 'invld'.
The RFC (5424) says that "Facility values MUST be in the range of 0 to 23
inclusive," so it seems like rsyslog is correct in expecting something in that
range.
Jeremy
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
