On 17.10.2011 11:44, Rainer Gerhards wrote: > I am not sure if I understood your scenario correctly. Is this your lab > setup: > > - make rsyslog monitor a file f > - continuously append lines to f > - send messages both to remote server and log them locally > - break connection to remote server > - some more lines from f are logged locally, and then no more lines form f > are processed
almost, you forgot the messages sent by logger via syslog() :) - make rsyslog receive messages via syslog() - make rsyslog monitor a file f - continuously send messages via syslog() and append lines to f - log messages locally and send all messages to remote server - break connection to remote server - after some time rsyslog stops logging any messages, from syslog() and f - after some more time all applications logging via syslog() almost hang ( a simple login takes ages) > If so, I think I can explain what happens. The file monitor is flagged as a > full delayable message source. That means if it begins to fill queues, the > input can be blocked without causing harm. This is most useful in (almost) > all setups, because otherwise a large file monitor would copy over > potentially huge amounts of data to a queue file if a remote destination goes > down (in fact, we have seen this in earlier releases). However, this means > that the file monitor is actually blocked, and thus it will also not submit > messages for local submission. I think this is what happens here (it took me > a while to actually understand the scenario...). i wouldn't care if only the file monitor blocks but the real problem is the hanging syslog() call. why does a blocked file monitor also blocks the processing of messages sent by syslog()? i expected that at least messages sent via syslog() are processed but rsyslog stops to log anything and thus these messages are lost because they are not spooled to disk. > I can see that the assumption that a file monitor message can be delayed may > not be valid in some cases, e.g. with extended offline time of a receiver. > However, trust me that it is useful in many more cases. So what could be > done, if I am right with my analysis, is to create a config setting so that > imfile's priority can be changed to non-delayable. This probably solves your > situation, but you should note that this can place considerable burden on > your server in case of failover. Also, you probably need around two to three > times the disk space of those files that are to be enqueued. i think it's reasonable to let the file monitor block but this shouldn't affect other input sources, right? if your proposed solution fixes the hanging syslog() calls too, i'm willing to try and test it :) regards, -ap _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
