> -----Original Message----- > From: Marcin Mirosław [mailto:[email protected]] > Sent: Friday, June 01, 2012 12:01 PM > To: rsyslog-users > Cc: Rainer Gerhards > Subject: Re: [rsyslog] rsyslog-5.8.11 omit syncing is always on? > > W dniu 31.05.2012 12:33, Rainer Gerhards pisze: > > Hello! > > > I tried to reproduce the problem today, but had no success with that. I went > through several cycles but finally gave up. > > > > Then, I reviewed the debug log that you sent with some mail in this thread. > > In > that log, it looks like the action queue fills up and then the main queue > begins to > fill up as well. When the main queue is full, messages are discarded with the > usual 1 (or 2) second timeout. This seems to be the cause of the problem. > > > > HOWEVER, that is a different scenario than what you describe above, with > only "several dozen of lines". Would it be possible that you provide me a > debug > log for the above scenario? As I said, all works perfectly for me. I even > tried to > shut down the remote RELP server, but that had no influence at all (as, of > course, it should be). > > Rainer, > i've used one-liner: > for x in $(seq 1 1000); do logger "seq:${x} time:$(date +%T)" ; echo > "write_to_exim_log:${x} time:$(date +%T)" >> /var/log/exim/exim_main.log > ; sleep 0.4; done > (Thunderbird wraps lines:/) > After seq:206 rsyslogd stops to write to wszystko.log. I've forgot to > say earlier i'm testing with relp destination unavailable.
Ah, OK, that is quite a bit more than a handful of messages. I never tried with that volume. > Before i run test i've done: > rm /var/log/exim/exim_main.log && touch /var/log/exim/exim_main.log && > rm /var/spool/rsyslog/* > > After rsyslogd stops write to wszystko.log there in debug log i can see > message "wti worker in full delay timed out, checking termination..." > I'll send you debug.log offlist, there is no reason to send 330kB to > every subscriber. Thx, the debug log is actually quite interesting. At first, it looks like the queue limit is hit in full delay mode (which makes some sense), but on second look the exact occurrence looks strange. I'll try to reproduce the problem with your new instructions. If I still cannot get the problem to show up, I'll probably create an instrumented version for you (I need some more insight than standard debug messages provide). > Julio, > i tested your settings. Sadly, in my case it doesn't change anything. > > Furthermore i can see rsyslogd doesn't create queue files with messages > which wasn't send to relp receiver. That's intentional. There is little point in having imfile pull all messages into the queue files. So imfile should be delayed. HOWEVER, this is intended to happen in a way that does not affect other traffic. Obviously something fails here. It would also probably good to have a way to change the default behavior, in case you want it differently (e.g. the file is rotated away too quickly, so that you actually want to copy data to the queue files). Rainer > > Regards, > Marcin _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards
