>On Sat, Jan 3, 2015 at 8:38 AM, Alexander Bluhm <[email protected]> >wrote: >> My goal is to make logging via syslog reliable. At least I want >> to see when a message gets lost. >> >> So my idea is to write a kernel log message if sendsyslog(2) cannot >> deliver a message. Then you see the problem on the console and in >> the dmesg buffer. If syslogd comes back later, you will also get >> the error into the log files via /dev/klog. >> >> comments? ok? > >Idea makes sense, but I wonder whether rate limiting is the best way >to handle logging of the failures. My first instinct would be to log >the first failure, and then just count failures until a success >occurs, at which point the count of the intervening failures should be >reported.
I had a discussion with Alexander where I expressed concern about the syncronous nature of console output, and that rate limiting may not be enough. On slow console devices, this can have significant performance effects even with the rate limiting. To me this code block fundamentally feels like it is using the dmesg buffer as a debug scaffold, because the idea is that syslogd should not fail. I know what he wants, but I am wary of the kernel having this heavy cost to a system call which was designed to be so simple and clean.
