Re: ASL_LEVEL_DEBUG
Re: ASL_LEVEL_DEBUG
- Subject: Re: ASL_LEVEL_DEBUG
- From: John Devlin <email@hidden>
- Date: Tue, 11 Mar 2008 16:52:01 -0700
Marc, I got that from your post yesterday. Thanks for showing how it's
done:
sudo syslog -c syslogd -d
sudo -K
syslog -s -l 7 "Houston, we have a problem."
writes the debug message to the system log.
What's odd is that man syslog(1) recommends
sudo syslog -c syslog -d
instead. Yet according to man syslog(1)
syslog -c <process> -<level>
raises the per-process filter for <process> to <level>. Hence the
example given in the man page shouldn't have any effect on syslogd's
filter. I thought it was just a typo in man syslog(1), but to my
surprise the example actually works! IMHO that's not a good thing.
You've pointed out the importance of the distinction between filters
on the asl client and the filter on the asl server. The former
determine which among the messages syslog sends will get through to
syslogd. The latter determines which among the messages syslogd
receives will get written to the system log. Yet here is a case in
which the behavior of syslog and the content of its man page make no
sense unless there's no distinction between asl's client and server-
side filters. For informed users that violates the principle of least
surprise. For novices, it's misleading.
I found the results of
syslog -c syslog
similarly surprising. According to man syslog(1)
syslog -c <process>
returns the current per-process filter for <process>. There is no per-
process filter for syslog, or at least not one preventing debug-level
messages from being sent to syslogd--if there were, then according to
man syslog(1), it would take precedence over
asl_set_filter(ASL_FILTER_MASK_UPTO(ASL_LEVEL_DEBUG));
and if that were true, no program would be able to send debug messages
to syslogd, which is clearly not the case. So I expected 'syslog -c
syslog' would return either "Emergency - Debug", "Per-process filter:
OFF" or something else along those lines indicating that syslog has no
per-process filter preventing debug messages from getting sent.
Instead the command returns the current per-process filter for
syslogd. Again, IMHO that behavior is unfortunate. It would make sense
only if there was no distinction between asl's client and server
filters, whereas as you point out it's crucial to understand the
difference between the two. For informed users this too violates the
principle of least surprise, and for novices it's equally misleading.
Together the two cases conspire to encourage programming-by-
coincidence. A novice who infers from the results of 'syslog -c
syslog' that the asl client is filtering info and debug messages is
apt to conclude that 'sudo syslog -c syslog -d' works because it
disables a client-side filter, thereby missing the point entirely.
At any rate, I'll file a bug report along those lines for
consideration. These difficulties aside, the more I learn about asl
the more impressed I am with its elegant, modular design. Maybe I'm
missing something here.
John
On 11 Mar 2008, at 9:00 AM, Marc Majka wrote:
The "master" filter is a global filter that applies to on the client
side (i.e. it controls what messages are sent TO syslogd). It
doesn't change the database filter on the server side.
--
Marc Majka
On 10 Mar, 2008, at 14:58, John Devlin wrote:
Your suggestion is also mentioned in man syslog(1), which claims it
will "cause all processes to log messages from Emergency to Debug,"
thereby giving rise to the impression it should work. However it
doesn't. Eg
% sudo syslog -c 0 -d
Password:
Set Master syslog filter mask: Emergency - Debug
% sudo -K
% syslog -s -l 7 "Houston, I think we have a problem."
won't write a debug message to the system log.
You're right that invoking the command 'sudo syslog -c 0 -d' sets
syslog's "master" filter to let everything through, including debug
messages. However by default the master filter is off, which
according to man syslog(1) means "it has no effect", ie everything
gets through anyways. And as I mentioned, I checked to make sure
the master filter hadn't been turned on, witness
% syslog -c 0
Master filter mask: Off
So setting the filter mask up to debug doesn't help in my case. In
fact, I can't think of any use case for
% sudo syslog -c 0 -d
given that it's equivalent to
% sudo syslog -c 0 off
I'll file a bug against the misleading line in man syslog(1) and
suggest a different example which sets the master filter to cutoff
messages above a certain level, which I gather from man syslog(1)
is the master filter's intended purpose.
John
On 10 Mar 2008, at 7:18 AM, Paul Nelson wrote:
You need to do:
sudo syslog -c 0 -d
This sets the logging level to debug.
From: John Devlin <email@hidden>
Date: Sun, 9 Mar 2008 19:43:59 -0700
To: Darwin Dev <email@hidden>
Subject: ASL_LEVEL_DEBUG
I'd like to send debug messages to the asl system log on Leopard
without using sudo, but haven't had any success.
I compiled and ran a test program (see below).
On 2 Oct 2006, at 10:23 AM, Marc Majka wrote:
Here's a small test program that will also send a "test" message
with the "raduis" facility:
#include <asl.h>
#include <string.h>
int main()
{
aslmsg m = asl_new(ASL_TYPE_MSG);
asl_set_filter(NULL, ASL_FILTER_MASK_UPTO(ASL_LEVEL_DEBUG));
asl_set(m, "Facility", "radius");
asl_log(NULL, m, ASL_LEVEL_DEBUG, "test");
return(0);
}
After which I tried to read the message back from the log
% syslog -k Facility radius
% syslog -k Level 7
but didn't find anything. I checked to make sure the the master
filter
was off, and it was.
% syslog -c 0
Master filter mask: Off
So I compiled and ran a second test program (see below).
If you read through the man page, you'd also find that the
following
code *should* work:
aslclient a = asl_open(NULL, "radius", 0);
asl_set_filter(NULL, ASL_FILTER_MASK_UPTO(ASL_LEVEL_DEBUG));
asl_log(a, NULL, ASL_LEVEL_DEBUG, "test");
asl_close(a);
return(0);
But due to a bug in asl_open(), it doesn't. Sorry about that!
The
bug will be fixed in 10.5 (Leopard).
That didn't work either. I searched the lists for 'ASL_LEVEL_DEBUG'
but didn't come up with anything beyond the two tests above. Any
ideas
why neither of those two programs work on 10.5.2? Any ideas what
would?
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden