Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Aaron Griffin (phrakture)
Architecture All
Severity Very Low
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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

This task blocks these from closing
 FS#6980 - syslog-ng stats flooding syslog 
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
Comment by Dan McGee (toofishes) - Wednesday, 02 July 2008, 05:33 GMT
I don't think we really want the final flag either; no other log lines contain that. Any objections to this patch?
Comment by Glenn Matthys (RedShift) - Friday, 12 December 2008, 20:41 GMT
Status: not implemented. Version 2.0.9-1 in core. Version 2.1.3-1 in testing.
Comment by Aaron Griffin (phrakture) - Friday, 12 December 2008, 22:09 GMT
In testing now, 2.1.3-2
Comment by Desmond Cox (pointone) - Thursday, 08 January 2009, 05:17 GMT
Still doesn't work as expected.

'/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'.
Comment by Desmond Cox (pointone) - Thursday, 08 January 2009, 05:21 GMT
Actually, my last post should probably be posted as a new bug for the 'acpid' package, as the above patch does correctly solve the problem of 'syslog-ng' statistics logging to 'acpid.log'.

However, the quotes still aren't necessary for the filter 'program(acpid)'.
Comment by Aaron Griffin (phrakture) - Thursday, 08 January 2009, 07:32 GMT
Hmm regarding this new bug, would using "logger -t" help us? We would have to add some new filter by default.

However, does running acpid with the -l flag work (ignoring the extraneous messages from handler.sh)?
Comment by Dan McGee (toofishes) - Thursday, 08 January 2009, 12:06 GMT
Is "logger -t acpid[$PIDOFACPID] <message>" what we want? Seems to generate the right output in my messsages.log at least...
Comment by Desmond Cox (pointone) - Thursday, 08 January 2009, 15:28 GMT
Just 'logger -t acpid' works fine for me; acpid doesn't log its PID by default, anyhow. I had changed to 'logger -p local3.notify' and modified the filter to watch the 'local3' facility--but the 'tag' switch is much nicer.

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.
Comment by Aaron Griffin (phrakture) - Thursday, 08 January 2009, 20:53 GMT
Would adding logger -t acpid be good as a sane default and close this bug? Haven't tested to see what kind of messages this adds.
Comment by Desmond Cox (pointone) - Thursday, 08 January 2009, 23:19 GMT
I believe so, yes. The key is how to best implement it:

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).

Loading...