FYI, we have found experimentally that syslog-ng 3.1.2 will use poll() on /dev/console without complaining, and that doing this actually seems to solve the problem. We have not been able to reproduce the console hang after switching the console destination to use poll() instead of file(). Paul Krizak 7171 Southwest Pkwy MS B200.3A MTS Systems Engineer Austin, TX 78735 Advanced Micro Devices Desk: (512) 602-8775 Linux/Unix Systems Engineering Cell: (512) 791-0686 Global IT Infrastructure Fax: (512) 602-0468 On 01/27/11 10:17, Matthew Hall wrote:
On Thu, Jan 27, 2011 at 11:04:01AM +0100, Sandor Geller wrote:
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.
I'm sorry but our opinion doesn't matter too much... If I read the linux kernel code correctly then for regular files poll() isn't even implemented at the VFS layer so files are always writeable. syslog-ng's behaviour of not wasting time for calling poll() for regular files is correct.
Of course I could be wrong so BalaBit folks are more than welcome to chime in :)
Regards, Sandor
Could you not just call something which checks for space in the block device?
Imperfect but certainly better than doing nothing.
Matthew. ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.campin.net/syslog-ng/faq.html