On Thu, 8 Oct 2015, Rainer Gerhards wrote:
2015-10-08 7:07 GMT+02:00 Rainer Gerhards <[email protected]>:
Sent from phone, thus brief.
Am 07.10.2015 23:15 schrieb "David Lang" <[email protected]>:
I would have expected rsyslog to show errors in it's logs and/or problems
in impstats when maxopenfiles is hit and it can't open a file for output.
ACK, that strongly smells like a bug.
I have looked into it, and I now think I know why no error message was
generated: this can lead to an error message loop. This is the case if
the error message is written to a file that itself had the error. So
the next write will also generate one and then rsyslog is busy
reporting the error that happened during error reporiting ... and so
on. There is the default rate-limiter which places some upper bound on
the iterations, but this still can get very ugly.
Note that tracking the "already reported" state for each file is more
or less out of question -- that would mean we would need to maintain a
list for all files that ever have been tried. Or is that acceptable?
In any case, this means we need to add a lot of code for this error
tracking.
Any other ideas or suggestions in general?
1. it should result in a failure, not a processed for that message in impstats
2. it should report via stdout/stderr
3. it should be reported as part of dynafile stats (since that's where it's most
likely to be hit)
4. it would need to be rate limited, even if you don't have a message loop,
having every new message generate an error message is not going to work. Can teh
standard backoff for suspended/failed outptus be used here?
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
