Am Dienstag, 20. Oktober 2009 11:32:55 schrieb Rainer Gerhards: > Marc, Hi Rainer,
> > I finally had some time to look into the issue. The problem actually is > rooted in the shutdown sequence, which is rather complex in v3/v4. I am > right now working on great simplification in v5, which will lead to more > robust and even better performing code. > > Thanks to that work, I think I was able to quickly find the culprit and > also to develop a patch. In my lab it works, and in theory it works as > well, but practice is always another beast... > > So I would appreciate if you could give it a try. It is a pre-release of > what once will become 4.4.3 and is available at: > > http://download.rsyslog.com/rsyslog/pre/rsyslog-4.4.3.tar.gz Thanks very much! Now it works as expected with one exception: In my test that I did now I put an ID into each log-message to see if no messages get lost. That way I found that one message always gets lost when I do the following: * DB and rsyslogd started * Start logger loop with ID (slow message rate): X=1; while true; do logger -t spool-test "no real message here... (ID=$X)"; X=$((X+1)); sleep 3; done & * stop DB server, spooling to mem starts * start another logger loop to force DA spooling: while true; do logger -t spool-test "no real message here..."; done & * watch spool dir: as soon as a queue file is being created: stop both loops ("fg" followeg by ctrl-c, two times) * stop rsyslogd: qi is file being created now! now there should be no lost message, right? * start DB server * start rsyslogd * check the log: *one* of those ID=$X messages is lost. I did that test two times. -Marc _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
