[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: Fwd: syslogd kernel messages facility
From:       walter harms <wharms () bfs ! de>
Date:       2010-11-23 14:52:09
Message-ID: 4CEBD519.4020906 () bfs ! de
[Download RAW message or body]



Am 23.11.2010 12:14, schrieb Sergey Naumov:
> It seems that it is glibc/uclibc bug, because in busybox's klogd we
> call syslog(priority, "%s", start) with priority <=7 (so facility is
> zero), but uclibc code (0.9.30.2) for syslog function uses default
> LOG_USER facility for these messages. Even specifying LOG_KERN in
> openlog("kernel", 0, LOG_KERN)  in klogd.c does not help:
> ...
> static int LogFacility = LOG_USER;
> 
> void openlog(..., int logfac)
> {
> ...
>     if (logfac != 0 && (logfac &~ LOG_FACMASK) == 0)
>         LogFacility = logfac;
> ...
> }
> 
> In this function zero facility is treated like "unspecified", but in
> fact zero facility is LOG_KERN facility.
> 
> In uclibc 0.9.31 it is fixed, but for glic-2.7 from debian 5.0.0 lenny
> I see incorrect behavior. May be we should make an ugly optional
> workaround and use in klogd some reserved facility value (for example,
> LOG_LOCAL7 or smth) for LOG_KERN, and then restore correct facility
> number in syslogd? Does anybody know, how often LOG_LOCAL[0-7] are
> used and whether it is safe to use them for workaround purpose?
> 
> Sergey Naumov.

hi Sergey,
thanks for reporting and analyzing that issue.

I do not think that ugly workarounds are a solution for anything.
It should be noted on the webpages/in the documentation that there
is an issue with logging but that would be enough.

btw:
i use  LOG_LOCAL in my scripts as cheap possibility to send them into
filters. (see logger) :)

re,
 wh
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]