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@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