Bug 107767 - logwatch still sometimes runs removeheaders before onlyservice
Summary: logwatch still sometimes runs removeheaders before onlyservice
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: logwatch   
(Show other bugs)
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Elliot Lee
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-22 19:54 UTC by Gilles Detillieux
Modified: 2007-04-18 16:58 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-20 19:36:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to fix problem by using 4-digit keys with leading zeros (1.69 KB, patch)
2003-10-22 19:57 UTC, Gilles Detillieux
no flags Details | Diff

Description Gilles Detillieux 2003-10-22 19:54:49 UTC
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
it does.

Version-Release number of selected component (if applicable):

How reproducible:

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
be reported.

Additional info:

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
of scripts.

Comment 1 Gilles Detillieux 2003-10-22 19:57:05 UTC
Created attachment 95400 [details]
Patch to fix problem by using 4-digit keys with leading zeros

Comment 2 Elliot Lee 2004-08-20 19:36:22 UTC
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!

Note You need to log in before you can comment on or make changes to this bug.