> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Andreas Piesk > Sent: Monday, October 17, 2011 8:01 PM > To: [email protected] > Subject: Re: [rsyslog] rsyslog stops local logging and local logging > hangsif remote destination is unresponsive > > 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() :)
Indeed and that is another story. Of course, that should not be blocked. Trying to dig deeper into the issue: what happens if you do not monitor the file but just use syslog() input. Does it then block? Rainer > > - 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 _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
