Red Hat Bugzilla – Bug 75859
Logwatch Cron.daily symlink not being executed
Last modified: 2008-05-01 11:38:04 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: 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.
One box here seems to be showing the same symptoms
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.
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 :)
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.