Re: syslog and LOG_KERN broken

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   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