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
