Red Hat Bugzilla – Bug 107767
logwatch still sometimes runs removeheaders before onlyservice
Last modified: 2007-04-18 12:58:42 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
A frequently reported bug in the past was that logwatch didn't produce any
output for some services because it was running the removeheaders script before
the onlyservice script, so it couldn't find the service in the log entries.
(See bug 72809, bug 75086, bug 104658.) This was supposed to be fixed in
logwatch 4.x. For the most part it was, because it now assigns numbers to these
shared scripts and sorts the keys so that the scripts come out in the right order.
However, it still occasionally gets it wrong! The reason is the numbers it
prepends to the keys don't have leading zeros, so for example, 9-*onlyservice
comes after 10-*removeheaders, not before. This will only affect one service on
a given machine - whichever one is assigned the numbers 9 and 10 for these
shared scripts. The trouble is, this will vary from one machine to another, so
a series of machines running Red Hat 9 will all randomly drop one service from
their logwatch reports, which might be a service the machine doesn't use, or one
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run logwatch --debug 8 --print
2. Look in the output for the "Service Name:" entries that use both *onlyservice
and *removeheaders, and of these, look for the ones that prefix 9- and 10- to these.
3. Look in the final report, and you should see that nothing comes out for that
particular service. It's tricky to reproduce this consistently because the
service will vary from one machine to the next, so you may not get a service
that actually does have log entries.
Actual Results: The report is missing data for one service.
Expected Results: All services for which there are relevant log entries should
The fix to this is to prepend a number with leading zeros so the keys sort
properly. I used a 4-digit number to be assured it will work for a huge number
Created attachment 95400 [details]
Patch to fix problem by using 4-digit keys with leading zeros
Thanks for the patch. It looks like the author has applied the patch
in a slightly modified form as of logwatch-5.2.2 - all is well!