syslog and LOG_KERN broken
Mark Kettenis
kettenis@wins.uva.nl
Mon Mar 20 05:08:00 GMT 2000
Date: Mon, 20 Mar 2000 13:00:37 +0100
From: "Dr. Werner Fink" <werner@suse.de>
On Mon, Mar 20, 2000 at 02:51:44AM +0100, Matthias Urlichs wrote:
> Hi,
>
> "Dr. Werner Fink":
> > Hmmm ... the klogd of sysklogd-1.3-33 has its own syslog() which is
> > a copy of an older syslog() libc5/glibc
>
> ... and which is broken.
>
> For proof, restart syslogd. Notice that klogd doesn't log any more;
> you'll have to restart klogd to fix it.
>
> (I just observed this on RedHat 5.1.)
>
> That kind of bug, long-solved in the glibc version of syslog(), is
> the reason why "has its own ANYTHING" is a bad idea in general.
Yep, fully agreed. This is exactly the reason why the interface
syslog() glibc should be usable for klogd. Currently it is not
possible to use syslog() from glibc, see misc/syslog.c, function
openlog_internal() which is called by openlog() ... as long as the
integer logfac can't be 0 (only) for klogd the klogd can't use the
syslog interface of glibc.
As I explained before, we cannot change the current interfaces. Are
you suggesting that we add a special entry-point to glibc just for the
sake of klogd? I don't think we should add special entry-points for
specific programs to glibc without a *very good* reason. IMHO opinion
none of the points raised in this thread provide that. The obvious
solution is fixing the bugs in the syslog() implementation that comes
with klogd, possibly by taking the syslog() implementation from the
latest glibc and adapting it to your needs. You'll probably want to
remove the locking since that's only needed for multithreaded apps.
This has the advantage that you'll be able to use the resulting klogd
on systems that are not using the latest glibc too!
If you realy think adding a new entry-point is the right solution,
you'll have to convince Ulrich Drepper, the glibc maintainer.
Mark
More information about the Libc-alpha
mailing list