Bug 75859 - Logwatch Cron.daily symlink not being executed
Logwatch Cron.daily symlink not being executed
Product: Red Hat Linux
Classification: Retired
Component: logwatch (Show other bugs)
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Elliot Lee
Depends On:
  Show dependency treegraph
Reported: 2002-10-14 01:11 EDT by Paul Dean
Modified: 2008-05-01 11:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-02-19 18:33:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paul Dean 2002-10-14 01:11:31 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1b) Gecko/20020820

Description of problem:
The symlink that is created by the installer in /etc/cron.daily is not being
executed at the cron daily times.

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

How reproducible:

Steps to Reproduce:
1.Reinstall logwatch rpm, after I have removed the symlink to make sure the
symlink was being created properly.
2.I have upgraded two machines from RH 7.3 to 8.0 and both have the same results
3.Created cron job in 'root' crontab, cron reports to be executed but no ouput
to be mailed.

Actual Results:  No output was genreated, cron's logs from cron.daily doesn't
report any execution.
Root's crontab reports execution but no output.

Expected Results:  A email generated and sent to root.

Additional info:

Searching through my log files, not error message is generated by cron or by
logwatch even with 'debug' set in the logwatch script.

I am aware of bug # 75086, but am not sure if it related in anyway, or may be
the cause of this problem.

I have choosen Security, as it is a total failure of this script via crond. I
believe it is necessary to have cron generated log reports.
Comment 1 Alan Cox 2002-12-18 15:41:10 EST
One box here seems to be showing the same symptoms
Comment 2 Matt Marnell 2003-01-03 02:09:32 EST
The following seems to have helped, but not entirely happy with the output quite

*** logwatch.pl 2003-01-03 02:01:07.000000000 -0500
--- logwatch.pl.orig    2002-08-08 13:12:34.000000000 -0400
*** 524,530 ****
     $FilterText = " ";
!    foreach $ThisFile (keys %{$ServiceData{$Service}}) {
        if ($ThisFile =~ s/^\*//) {
           $FilterText .= ("| " . $BaseDir . "scripts/shared/" . $ThisFile . " "
. $ServiceData{$Service}{"*" . $ThisFile} );
--- 524,530 ----
     $FilterText = " ";
!    foreach $ThisFile (reverse keys %{$ServiceData{$Service}}) {
        if ($ThisFile =~ s/^\*//) {
           $FilterText .= ("| " . $BaseDir . "scripts/shared/" . $ThisFile . " "
. $ServiceData{$Service}{"*" . $ThisFile} );

That reverse keys appears to be what has been killing the script.  It was
getting the sets of filters backwards such that 'removeheaders' was removing the
headers before 'onlyservice' was grepping out the lines with the service name.

The thing I'm still not happy with is the new named filtering, which appears to
differ greatly from the old behavior, ignoring many things.
Comment 3 Elliot Lee 2003-02-19 18:33:59 EST
So the real trick is probably to run 'onlyservice' before 'removeheaders' but
otherwise preserve the order?

You may want to talk directly to the logwatch author about this one - I'm pretty
much a patch shoveller on this package :)
Comment 4 Matt Marnell 2003-02-19 18:50:13 EST
I don't know how it can possibly work otherwise.  Running through the
progression of things it does by hand, it doesn't leave anything usable in the
output otherwise.

LogWatch is an fine utility, but as far as fixing it, I wouldn't want to have to
maintain it.  I'll refer the owner to the ticket.  I'm happy enough with having
it work again.

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