OK, then this seems to be a bug indeed. I suggest you file a bug report with bugzilla. Usually, I tend to forget about those things if they exist on the mailing list only :( When they are in bugzilla, I pick them as soon as I have time to do so. It would probably wise to include a link to the mailing list archive.
I will try to look into this ASAP, but it may take some while as I am pretty busy right at the moment. Thanks, Rainer > -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 1:13 PM > To: rsyslog-users > Subject: Re: [rsyslog] Buggy pipe behaviour > > Am 29.07.2010 12:43, schrieb Rainer Gerhards: > >>> This sounds like intended behavior. When an action fails > >>> (pipe fails when nobody reads and it is tried to write to > >>> it), rsyslog retries the configured number of times and > >>> then suspends the action for the configured period (at > >>> least I think it is configurable, you need to look up the > >>> details). Only after this period the action is retried. > >>> If it fails again, it is re-suspended, but this time with > >>> a longer suspension period. This is done so that rsyslog > >>> does not spent a lot of time on actions known to be failing. > >> > >> So you say, if i wait long enough the messages should receive > >> the end of the pipe? > > > > Yes, that's what I assume. > > I tried $ActionResumeRetryCount -1 and default $ActionREsumeInterval 30 > and your assumption seems to be wrong. :( > > If the receiver is available again after about 20 seconds (while > flooding syslog with the mentioned script) it reads the content of the > pipe and nothing more. > > The debug log from rsyslogd endless says > > ----------->snip<---------------- > 1711.687960300:b6644b70: main Q: enqueueMsg: cond timeout, dropping > message! > 1711.687982929:b6644b70: main Q: EnqueueMsg advised worker start > 1711.687992707:b6644b70: --------imuxsock calling select, active file > descriptors (max 3): 3 > 1711.688016872:b6644b70: Message from UNIX socket: #3 > 1711.688034054:b6644b70: main Q: queue nearly full (10000 entries), but > could not drop msg (iRet: 0, severity -1) > 1711.688042086:b6644b70: main Q: enqueueMsg: queue FULL - waiting to > drain. > 1713.688370002:b6644b70: main Q: enqueueMsg: cond timeout, dropping > message! > 1713.688419171:b6644b70: main Q: EnqueueMsg advised worker start > 1713.688441799:b6644b70: --------imuxsock calling select, active file > descriptors (max 3): 3 > 1713.688488314:b6644b70: Message from UNIX socket: #3 > 1713.688518904:b6644b70: main Q: queue nearly full (10000 entries), but > could not drop msg (iRet: 0, severity -1) > 1713.688534200:b6644b70: main Q: enqueueMsg: queue FULL - waiting to > drain. > ----------->snap<---------------- > > So it seems that rsyslogd does not detect that the receiver is > available again (as mentioned before this only occurs if the receiver > is not available for a "longer" time - probably the time the pipe runs > full). > > Steffen > > _______________________________________________ > 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
