Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 75086 - logwatch does not generate messages for all configured categories
Summary: logwatch does not generate messages for all configured categories
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: logwatch
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Elliot Lee
QA Contact:
Depends On:
Blocks: 80064
TreeView+ depends on / blocked
Reported: 2002-10-04 09:59 UTC by Manfred Hollstein
Modified: 2008-05-01 15:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2002-10-15 13:37:24 UTC

Attachments (Terms of Use)
/var/log/messages file used to run logwatch with (deleted)
2002-10-04 10:04 UTC, Manfred Hollstein
no flags Details
Expected results - generated with RHL 7.3's perl-5.6.1 (deleted)
2002-10-04 10:07 UTC, Manfred Hollstein
no flags Details
Results generated on the same system from the same messages, but using the standard perl-5.8.0 (deleted)
2002-10-04 10:08 UTC, Manfred Hollstein
no flags Details

Description Manfred Hollstein 2002-10-04 09:59:42 UTC
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)

How reproducible:

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".

Additional info:

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

Comment 1 Manfred Hollstein 2002-10-04 10:04:25 UTC
Created attachment 78584 [details]
/var/log/messages file used to run logwatch with

Comment 2 Manfred Hollstein 2002-10-04 10:07:05 UTC
Created attachment 78585 [details]
Expected results - generated with RHL 7.3's perl-5.6.1

Comment 3 Manfred Hollstein 2002-10-04 10:08:30 UTC
Created attachment 78586 [details]
Results generated on the same system from the same messages, but using the standard perl-5.8.0

Comment 4 Douglas Kilpatrick 2002-10-08 15:00:41 UTC
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.

Comment 5 Need Real Name 2002-10-08 21:06:37 UTC
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.

Comment 6 Manfred Hollstein 2002-10-09 06:47:59 UTC
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

Comment 7 Need Real Name 2002-10-15 13:37:18 UTC
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/ 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).

Comment 8 Elliot Lee 2002-10-16 18:02:04 UTC
Logwatch 4.0 fixes

Comment 9 Eric Hopper 2002-12-19 13:56:55 UTC
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.

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