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.
Here's the relevant snippets from our configuration:
source s_local { # standard Linux log source (this is the default place for the syslog() # function to send logs to) unix-stream("/dev/log"); }
it's somewhat better to use unix-dgram() for /dev/log
source s_kernel { # messages from the kernel file("/proc/kmsg" program_override("kernel")); };
log { # /var/log/syslog-ng.log source(s_self); destination(d_self); };
filter f_console { # Stuff that goes to the console ( facility(local1) and priority(info) ) or ( priority(emerg) ); };
destination d_console { file("/dev/console"); };
log { # Console source(s_local); source(s_kernel); source(s_self); filter(f_console); destination(d_console); };
and here you connect a stream source (/dev/log) with /dev/console Regards, Sandor