> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Marcin Miroslaw > Sent: Monday, June 04, 2012 10:35 AM > To: [email protected] > Subject: Re: [rsyslog] rsyslog-5.8.11 omit syncing is always on? > > W dniu 2012-06-01 15:24, Rainer Gerhards pisze: > > Yes, that was exactly the problem. A patch is available here: > > > > > http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=fd46d10a4f49da35758ab > 9201f6f863d69d5d4f5 > > > > It works for me, at least during quick testing. Would be great if you could > > also > try it out. > > > > Note, however, that it does not (and cannot) solve the issue that a > > filled-up > action message queue will cause delays on the main queue. You can reproduce > this problem if you remove the disk queue and let your script run. There is no > way to prevent this without discarding messages in the action queue. However, > I > need to check if the action queue is configurable enough so that one can > configure immediate discarding on queue full state. I think that's currently > not > possible. > > Hello! > > The patch is very short but works!:) Great!
> I think i have to read much more about queues in rsyslog. But i tried > mentioned example. I turned off diskqueue ( commented out > "$ActionQueueType" and "$WorkDirectory" ), i added If you comment out queueType, you keep the action without a queue, so it is sync and any delay will stop processing on the main queue as well. To just remove the disk queue, simply remove the queue file name directive. > "$ActionQueueTimeoutEnqueue 0". Now i can observe: > - debug log (when message arrives): > > > 7904.390975526:7f604188e700: --------imuxsock calling select, active file > descriptors (max 3): 3 > > 7904.391001800:7f604188e700: Message from UNIX socket: #3 > > 7904.391025237:7f604188e700: queue.c:2447:qqueueEnqObj: mutex > 0x1aa3360 waiting on lock, held by queue.c:2447 [7f604088c700] > > 7904.391030565:7f604188e700: queue.c:2447:qqueueEnqObj: mutex > 0x1aa3360 aquired > > 7904.391036094:7f604188e700: main Q: queue nearly full (10000 entries), but > could not drop msg (iRet: 0, severity 5) > > 7904.391041638:7f604188e700: main Q: enqueueMsg: queue FULL - waiting > to drain. > > 7904.980815118:7f604088c700: wti worker in full delay timed out, checking > termination... > > 7905.980900166:7f604088c700: wti worker in full delay timed out, checking > termination... > > 7906.391115725:7f604188e700: main Q: enqueueMsg: cond timeout, > dropping message! > > 7906.391138282:7f604188e700: queue.c:2459:qqueueEnqObj: mutex > 0x1aa3360 UNlocked > > 7906.391143964:7f604188e700: main Q: EnqueueMsg advised worker start > > 7906.391153498:7f604188e700: --------imuxsock calling select, active file > descriptors (max 3): 3 > > - my one-liner takes ages to finish, in exim_log i can see one message > per two seconds (when main queue becomes full) > - nothing appears in /var/log/wszystko.log > - in debug log (when no message arrives to rsyslog) i can see: > 8192.787179727:7f604088c700: wti worker in full delay timed out, > checking termination... > 8193.787273011:7f604088c700: wti worker in full delay timed out, > checking termination... > > - everything starts to work correctly wneh relp destonation becomes > available > > Is everything correct in this behavior? Especially long executing of logger? Yes, because you run the action in direct mode. Rainer > Thanks for fix! > 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 _______________________________________________ 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
