[syslog-ng] syslog-ng deadlock if /dev/console locks?

[Balazs Scheidler]

On Wed, 2011-01-26 at 09:28 -0800, Evan Rempel wrote:
> Sandor Geller wrote:
> > Hi,
> > 
> > On Wed, Jan 26, 2011 at 5:10 PM, Paul Krizak <paul.krizak at amd.com> wrote:
> >> Interesting.  We are definitely not seeing the 10 sec timeout protection --
> >> it flat-out hangs.  But we are using a file destination for the console
> >> device.  We used to use a pipe() destination back in the syslog-ng-2.x days,
> >> but when I tried that in 3.x it complained loudly about it, and suggested
> >> using file() instead.  We never had this problem in syslog-ng-2.x.  Could it
> >> be that pipe() is actually the better/more correct way to write to the
> >> console?
> > 
> > Under the hood the file() and pipe() drivers were more or less the
> > same. The issue is that only the source side sets the timeout, the
> > destination doesn't so when a log arrives on a source other than
> > file() or program() then timeout never gets set. One notable
> > difference between file() and pipe() is that for files syslog-ng
> > assumes that the file is always writeable (which is true at least on
> > linux) while for pipes syslog-ng checks with poll() first so when the
> > 4k page used for the pipe is full then syslog-ng won't try to write to
> > the pipe effectively avoiding being blocked.
> 
> I loudly disagree. Files are not "always writable". We continue to bump into the
> case where something generates tones of logs and fills the filesystem. The files
> are not writeable when this occurs, and syslog-ng can never recover from this even
> when space is made available again. The lame logic needs to be applied to files
> as is done for all other destinations.

This should have been fixed in 3.2 already. (maybe earlier, I can't
remember exactly). And this is a different case than the one we
discussed.

-- 
Bazsi