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.
>From what you wrote, I think your use case would probably better be served by omprog, but I may be wrong. If you think about this route, you need to know that someone requested the functionality, but was never seen when it was done ;) So the module is only barely tested. Rainer > -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Steffen Sledz > Sent: Thursday, July 29, 2010 9:17 AM > To: rsyslog ML > Subject: [rsyslog] Buggy pipe behaviour > > We need to configure a pipe to connect the output to a special > application. Our configuration looks like this: > > ----->snip<-------- > $ModLoad imuxsock > $ModLoad imklog > $ModLoad immark > > $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat > > $RepeatedMsgReduction on > > *.* |/var/run/syslog2thinfs > > ... some other channels > ----->snap<-------- > > The fifo is created and has sufficient rights. > > Now we can see the following behaviour: > > No receiver connected to the pipe, rsyslog writes messages into it > > Receiver is connected, queued messages are read -> fine > > Receiver is disconnected, rsyslog continues writing messages into it > (just a few) > > Receiver is reconnected, queued messages are read -> fine > > Receiver is disconnected, rsyslog continues writing messages into it > (more than the pipe capacity?) > > Receiver is reconnected, *some queued messages* are read (but only up > to the pipe capacity?) > > After this *no more messages* reach the end of the pipe. > Disconnect/reconnect the receiver makes no difference. -> bad :( > > I believe this is a bug. May be some messages get lost because there is > no place for intermediate storage. But after reconnecting the receiver > new messages should pass the pipe again. Right? > > We've seen this with 5.5.4 and 5.5.6. You can reproduce the behaviour > using the following shell snippets. > > Sender: > ----->snip<-------- > i=0;while true; do logger -t count $i; i=$(($i+1)); done > ----->snap<-------- > > Receiver: > ----->snip<-------- > while true; do cat /var/run/syslog2thinfs ; done > ----->snap<-------- > > Regards, > 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
