[BusyBox] older 06.5 syslogd problem

Stewart Brodie stewart at metahusky.net
Tue Jan 27 23:07:31 UTC 2004


"Brian T" <btuch at usa.net> wrote:

> > > > I was wondering if anyone has seen the older busybox syslogd remove
> > > > the "<" character, and the next character after it when looking at
> > > > the 60.5 syslogd version?
> > >
> > > This looks like syslog is interpreting these entries as if they were
> > > coming from kernel printk output via klogd and interpreting the <?
> > > character sequences as log levels.  The kernel log levels are
> > > indicated by using special character strings at the front of log
> > > messages like "<0>", "<1>" etc.  They are defined in linux/kernel.h as
> > > macros KERN_EMERG, KERN_ALERT etc.
> > >
> > > I suspect it should only be accepting them at the start of the
> > > message, and only if they match the pattern '<' digit 0-7 '>'.
> >
> > I agree entirely.  The only flaw I see in the analysis is that the code
> > I see in busybox-0.60.5 klogd.c (that Gennady Feldman wrote and I helped
> > test, years ago) appears to do exactly that.  Is there a chance Brian
> > has an older busybox around, or a non-busybox klogd running?

I've actually looked at the source code now and discovered that busybox's
syslogd is responsible for this and it affects the latest 1.00pre CVS
versions too.

Quick hack workaround:

In sysklogd/syslogd.c, function serveConnection, inside the outermost while
loop at the start of the function, an integer called 'num_lt' is declared
and initialised to 0.  Initialise it like this instead:

  int num_lt = (*p != '<');

This will solve Brian's immediate problem - only '<' characters at the start
of the message will now be interpreted as priority markers.

However, I'm not certain what the desired correct behaviour actually is. The
code appears to be attempting to permit the first '<' character per line of
debug to represent the priority code rather than insisting on it being at
the start of the string.  The proper fix will depend on what the desired
behaviour actually is.

-- 
Stewart Brodie



More information about the busybox mailing list