Bug 75859

Summary:	Logwatch Cron.daily symlink not being executed
Product:	[Retired] Red Hat Linux	Reporter:	Paul Dean <paul>
Component:	logwatch	Assignee:	Elliot Lee <sopwith>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	medium	Docs Contact:
Priority:	high
Version:	8.0	CC:	matt, paul, p.van.egdom
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-02-19 23:33:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Paul Dean 2002-10-14 05:11:31 UTC

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:
Always

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 20:41:10 UTC

One box here seems to be showing the same symptoms

Comment 2 Matt Marnell 2003-01-03 07:09:32 UTC

The following seems to have helped, but not entirely happy with the output quite
yet.

*** 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 23:33:59 UTC

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 23:50:13 UTC

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.