User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20060109 Firefox/1.0.6 Build Identifier: When syslog-ng writes to a tty under Linux, for example as a result of a usertty directive, the write syscall to /dev/ttyN can ocassionally block indefinitely. One situation when this occurs is when the user has set XOFF (perhaps with Ctrl-S or Scroll Lock). Aside from the fact that this obvious prevents any further log messages from being written, /dev/log's buffer eventually fills up causing other programs to block writing to /dev/log. In extremis, this can render a machine inaccesible when ssh, etc., all block preventing access. Reproducible: Always Steps to Reproduce: 1. Check that there is a usertty("*") directive for (say) kern.emerg logs 2. Ensure syslog-ng is running 3. On console, press Scroll Lock 4. Log something, e.g. logger -p kern.emerg 'Foo'. 5. Repeat #4 many times; eventually it will hang trying to log
Created attachment 101464 [details, diff] Patch The attached patch (relative to the 2.0.0 release) fixes this by imposing a 15s timeout on all console writes. (This figure should perhaps be configurable, but for my immediate purposes 15s is quite sufficient.) I've only tested this patch on Linux.
I suspect that bug #69294 (which was never fully diagnosed and eventually closed as 'invalid') is a duplicate of this.
Did you send this patch upstream?
I sent it to the address the AUTHORS file and to their mailing list, though I've not had a reply and the mailing list archive is accessible to subscribers only so I've no way of knowing whether the patch was actually received. (The upstream doesn't extactly make it easy to submit patches ;-(.)
I talked with the upstream and they're not excited about this patch. There is a different, more general solution to this issue in the works for a future version of syslog-ng. I'm not inclined to make the patch part of the Gentoo package. Since upstream won't be absorbing the patch and the issue is very avoidable and understood, and since upstream is working on a feature to address this situation, I'm going to mark this bug as UPSTREAM. Please work with upstream on the feature for a future release of syslog-ng. Thanks.
