Red Hat Bugzilla – Bug 75086
logwatch does not generate messages for all configured categories
Last modified: 2008-05-01 11:38:04 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020809
Description of problem:
I'm using the standard configuration for logwatch from a new RHL 8.0
installation. On RHL 7.3 (using perl-5.6.1-34.99.6) logwatch is
generating messages for all sort of categories such as "Automount",
"Kernel", "ModProbe", "Named", "Samba", "Connections", and "SSHD".
On the same 8.0 system (using perl-5.8.0-55) only the categories
"Samba" and "Connections" are generated, the others are missing.
Version-Release number of selected component (if applicable):
logwatch-2.6-8 (+ perl-5.8.0-55)
Steps to Reproduce:
1.Stick the attached messages file into "/var/log/messages"
2.Run "logwatch" as root
3.Look at the generated email
Actual Results: Details for categories "Automount", "Kernel", "ModProbe",
"Named", and "SSHD" are missing!
Expected Results: Details for all configured categories should be shown.
Since details from the kernel are missing (such as attacks to the
firewall etc.), I'd rate this "Security related".
FWIW, I traced this issue down to an "incompatibility" of logwatch
with the perl version shipped with RHL 8.0. Using the version from RHL 7.3
(by creating two symbolic links such as
"ln -sf /7.3/usr/bin/perl /usr/bin/perl" and
"ln -s /7.3/usr/lib/perl5/5.6.1 /usr/lib/perl5")
instead, enables logwatch to print details for all categories again. See the
attached files for details:
1. /var/log/messages This one is the logfile I used to run logwatch with
2. logwatch-message-generated-by-perl-5.6.1-34.99.6.txt This contains
the messages as I expect them to be
3. logwatch-message-generated-by-perl-5.8.0-55.txt This one contains
the messages generated by the standard RHL-8.0 installation
and from the same /var/log/messages file
Created attachment 78584 [details]
/var/log/messages file used to run logwatch with
Created attachment 78585 [details]
Expected results - generated with RHL 7.3's perl-5.6.1
Created attachment 78586 [details]
Results generated on the same system from the same messages, but using the standard perl-5.8.0
See also but 72809
The basic problem is a dependency issue. The filters are dependant on each
other: One filter removes the time stamps, the other assumes the time stamps are
You can "fix" it for RHL 8.0 by futzing with sort/reverse when the keys when
constructing the filter list for running the individual logwatch scripts.
Obviously, this isn't the correct answer...
There are only two filters actually used, "OnlyService" and "RemoveHeaders", so
its easy to randomly get the right order from the hash table. However ... It
really needs depenency info.
The missing firewall info needs further comment. The firewall rules created by
lokkit does not do any logging. In addition, the kernel service in logwatch
can only parse ipchains logs - and since iptables is now used in 8.0, it will
no longer work even if dropped packets were logged.
I'm not using a firewall generated by lokkit. Due to whatever constraints I'm
still using my good'n'ole ipchains firewall. Look at the attached messages
ICK! Never rely on the raw order of items in a hash. In Perl 5.8.0, they changed the hash
This needs to be fixed properly. However, for people that HAVE to get this working, this is a
quick and dirty patch that works (but it is crappy programming, so don't attribute it to me).
This relies on the fact that by chance, the desired order of operations of "shared" scripts
happens to be their alphabetical order.
In the script /etc/log.d/scripts/logwatch.pl change lines 474 and 527 (or, you can do a search
on the keyword "reverse" as it only appears in the script twice). Change "reverse" to "sort"
both in both locations.
The proper fix is not to store these items in a hash, but rather in an array and use that order (or
its reverse). However, the above "reverse" to "sort" fix can be made more robust and "proper"
by renaming the scripts in the shared area from"scriptname" to "XX-scriptname" where XX is
a numeric that identifies the order (similar to the /etc/rc.d/rcX.d script order).
Logwatch 4.0 fixes
If you can do it, this needs to be released as a patch. I think missing log
messages represents a grave security risk.
You could argue that people who pay attention to the logs will notice the
missing bits and come find this bug, but I think that's expecting people to
spend an unreasonable amount of effort.
I'm creating a new open bug on this.