FS#10776 - syslog-ng Log Statistics are written to /var/log/acpid.log instead of /var/log/syslog.log
Attached to Project:
Arch Linux
Opened by Sebastian (sepo) - Saturday, 28 June 2008, 15:18 GMT
Last edited by Tobias Powalowski (tpowa) - Saturday, 07 March 2009, 16:17 GMT
Opened by Sebastian (sepo) - Saturday, 28 June 2008, 15:18 GMT
Last edited by Tobias Powalowski (tpowa) - Saturday, 07 March 2009, 16:17 GMT
|
Details
Description:
syslog-ng's log statistics are written to /var/log/acpid.log but are supposed to be written to /var/log/syslog.log The reason for this is a too generic filter that matches any log message that contains "acpid" "filter f_acpid { match("acpid"); };" and the "final" flag in the log statement, that prevents the log message from being logged to /var/log/syslog.log "log { source(src); filter(f_acpid); destination(acpid); flags(final); };" There are two possible solutions. Either change the filter to match exactly the acpid daemon "filter f_acpid { program("acpid"); };" or remove the "final" flag from the log statement. I would prefer the first solution. Example message log statistics message from syslog-ng: Jun 24 00:12:02 myarchlinux [info] syslog-ng[2196]: Log statistics; processed=\'center(queued)=38\', processed=\'center(received)=10\', processed=\'destination(acpid)=0\', processed=\'destination(console)=0\', processed=\'destination(debug)=0\', processed=\'destination(mail)=0\', processed=\'destination(user)=9\', processed=\'destination(uucp)=0\', processed=\'destination(messages)=0\', processed=\'destination(ppp)=0\', processed=\'destination(news)=0\', processed=\'destination(d_vdrlog)=9\', processed=\'destination(iptables)=0\', processed=\'destination(everything)=10\', processed=\'destination(lpr)=0\', processed=\'destination(cron)=0\', processed=\'destination(syslog)=1\', processed=\'destination(authlog)=0\', processed=\'destination(errors)=9\', processed=\'destination(kernel)=0\', processed=\'destination(daemon)=0\', processed=\'destination(console_all)=0\', processed=\'source(src)=10\' Additional info: * package: syslog-ng 2.0.9-1 * /etc/syslog-ng.conf Steps to reproduce: This is configured by default |
This task depends upon
Closed by Tobias Powalowski (tpowa)
Saturday, 07 March 2009, 16:17 GMT
Reason for closing: Fixed
Additional comments about closing: syslog-ng 3.0.1 in testing
Saturday, 07 March 2009, 16:17 GMT
Reason for closing: Fixed
Additional comments about closing: syslog-ng 3.0.1 in testing
'/etc/acpi/handler.sh' logs using 'logger'; therefore the filter 'program(acpid)' (note that quotes aren't necessary) doesn't correctly detect (un)handled event/action logs. All that is posted to '/var/log/acpid.log' is daemon start/stop messages. Event/action messages logged with 'logger' appear in 'messages.log', 'user.log' and of course 'everything.log'. I suspect this is why the filter was originally changed to 'match("acpid")', although that wasn't right, either.
The only messages in my logs from 'program("logger")' are ACPI messages, anyhow. I'm tempted to add a log to send 'program("logger")' to 'destination(acpid)', but I'm sure there are other programs that use 'logger'.
However, the quotes still aren't necessary for the filter 'program(acpid)'.
However, does running acpid with the -l flag work (ignoring the extraneous messages from handler.sh)?
And yes, 'acpid -l' works as well--but it's a tad too verbose for anything besides debugging purposes, in my opinion (at least 5 messages per event!) However, that's exactly what I was looking for while I reconfigure my power management goodness. Thanks for the tip; I've simply added the switch to my '/etc/rc.d/acpid' script while I play around. I don't think this should be the default, however.
a) Change each instance of "logger <message>" to "logger -t acpid <message>" in /etc/acpi/handler.sh
b) Add LOGGER="logger -t acpid" near the beginning of the script and replace each instance of "logger <message>" with "$LOGGER <message>" (or some other similarly descriptive var name)
I think (b) is nicer, but am no scripting guru by any means (I haven't tested it extensively, either).