[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#118856: xbase-clients: xconsole: loses messages (possible buffer overrun?)



Branden Robinson writes:
 > On Fri, Nov 09, 2001 at 10:51:05AM -0500, Jeff Sheinberg wrote:
 > > I have noticed this strange output in the "xconsole" window
 > > whenever I boot up my computer,
 > > 
 > >     Nov  9 08:28:55 eden-hda7 Nov  9 08:28:55 eden-hda7 Nov  9
 > > 08:28:55 Nov  9 09:52:31 eden-hda7 PAM_unix[793]: (login) session
 > > opened for user jsroot by jeff(uid=1001)
 > > 
 > > ie, the three "Nov  9 08:28:55" entries at the end of the window.
 > 
 > Yes, I've seen this behavior myself for as long as I've been using
 > xconsole on Linux, which has been a few years.  I looked over the
 > xconsole code recently in conjuntion with a separate issue, but cannot
 > think of a reason why this may be happening.

Hi Branden,

I think I finally realize what is happening here, due to a kind
person explaining to me (unfortunately, off list, and I have lost
their email), regarding this bug against "syslog-ng",

    Bug#192054: syslog-ng: STATS: dropped 71

So, if you agree with my explanation, which follows, then please
reassign this bug to the "sysklogd" package, which is the syslog
deamon that I had installed when the bug was first reported.

Basically, the problem is that the syslog daemon has to
communicate the errlog messages to the xconsole program through a
named pipe, but until xconsole is actually running, any writes to
the named pipe will be rejected (via SIGPIPE signal and/or EPIPE
error return) because the named pipe has not yet been opened for
reading.

Of course, the syslog deamon just ignores these errors, and
buffers the rejected messages internally, but eventually, the
syslog daemon's buffers will become full, resulting in
lost/truncated messages eventually being delivered to xconsole
when the named piped does become opened for reading.

I think that the syslog daemon should handle a buffer full
condition for a destination that is a pipe (perhaps any
destination that is not a local file) in a way that the the oldest
messages are deleted to make room for newer messages, rather than
the other way around, as is currently being done.

Thanks,
-- 
Jeff Sheinberg





Reply to: