2012/3/15 Rainer Gerhards <[email protected]>: >> I worked out a tool(enclosed) to help rebuild .qi file, in my case: > > Cool! You made my day (and probably that of many more users in the future)! > :-) > > [...] > >> Usage: >> recover_qi.pl -w WorkDirectory -f QueueFileName -d 8 > >> QueueFileName.qi > > I'll see if I can get it included with tomorrows' release. > >> However, I have no idea why the last queue file mq.00000787 was not >> deleted after last entry had been delivered. So did the mq.qi file. >> Both failed to survive across restart though. > > That's correct. Once the DA worker has become active, it shuts only down at > overall rsyslog shutdown. The idea behind this is that if the DA worker is > used once, chances are good it will be reused. This also saves a lot of > complex handling (which we had in v4). As long as the worker runs, the last > queue file, even if fully processed, is kept open. > >> When rsyslogd was busy processing disk queue, I sent a message vai >> logger(1), it almost immediately appeared in the /var/log/messages >> file. Why? Shouldn't it appear after the disk queue entries? > > No, the DA queue runs concurrently to new messages. In v4 we kept them in > sync, what cost an awful lot of performance. For the overall concurrency > issue, have a look at this conference paper: > > http://www.gerhards.net/download/LinuxKongress2010rsyslog.pdf > > The relevant info is in section 7.
Awesome work! With order information stored in messages themselves, database backend is even outstanding with sophisticated indexing. > > Rainer > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ Thanks, Kaiwang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/
