Created attachment 400047 [details] The missing zz-fortune file. Description of problem: In logwatch, one of the modules displays a random 'fortune' message at the bottom of the report. This is probably the only reason why I still read these emails. In recent versions of logwatch, /usr/share/logwatch/scripts/services/zz-fortune has been replaced with a zero-length file. Version-Release number of selected component (if applicable): logwatch-7.3.6-50.fc12.noarch How reproducible: Always Steps to Reproduce: 1. Install logwatch-7.3.6-50.fc12.noarch.rpm 2. Check /usr/share/logwatch/scripts/services/zz-fortune 3. Actual results: No fortune appears Expected results: A fortune should appear Additional info: I'm attaching the zz-fortune file from a previous version of fortune.
Fortune removal was intentional: https://bugzilla.redhat.com/show_bug.cgi?id=51093 However, one can write a patch which blocks sending the report if zz-fortune is the only participant, and then re-enable zz-fortune.
I get an access denied error for that bug; was it security related?
Oh. The bug is filed to the old "Red Hat Linux", that is probably the reason. The problem is that the report is sent every time the logwatch is run even when nothing happened on a machine, because of the zz-fortune. The report looks like this: ################### LogWatch 2.1.1 Begin ################## ---------------- Fortune ------------------ Smear the road with a runner!! ################### LogWatch End ##########################
Ok, after examining the code, no self-contained change to zz-fortune is possible, since zz-fortune's output is written to a pipe, and examining the memory space of the parent process is not acceptable for such a simple program. This solution adds a LOGWATCH_HAS_OUTPUT environment variable, which is a very small patch, doesn't interfere with unrelated modules, uses an already calculated variable, and can be used by other modules in the future. --- /usr/sbin/logwatch 2010-04-13 10:31:12.418486647 -0700 +++ /usr/sbin/logwatch.new 2010-04-13 10:31:06.264490659 -0700 @@ -1231,6 +1231,7 @@ output( $index_par, "\n --------------------- $ServiceData{$Service}{'title'} $BeginVar ------------------------ \n\n", "line"); } $has_output = 1; + $ENV{'LOGWATCH_HAS_OUTPUT'}=1; } output( $index_par, $ThisLine, "line"); } --- /usr/share/logwatch/scripts/serviceszz-fortune 2010-04-13 10:31:52.849497444 -0700 +++ /usr/share/logwatch/scripts/serviceszz-fortune.new 2010-04-13 10:31:45.702487214 -0700 @@ -6,6 +6,8 @@ my $env = ( $ENV{'REAL_LANG'} ? "LANG=".$ENV{'REAL_LANG'}." " : "" ). ( $ENV{'REAL_LC_ALL'} ? "LC_ALL=".$ENV{'REAL_LC_ALL'}." " : "" ); +if (! defined $ENV{'LOGWATCH_HAS_OUTPUT'}) {exit 0;} + if (($ENV{'PRINTING'} eq "y" ) && (-f "/usr/games/fortune")) { #print "\n\n------------------ Fortune --------------------\n\n"; system("$env /usr/games/fortune");
Penelope, thank you for creating the patch. When testing the patch I noticed that zz-disk_space is reporting the disk space every time, so zz-fortune can do the same thing (and it will never be reporting alone). So the patch is not necessary at the end. Sorry for that! I'll enable zz-fortune in the next F-12 and F-13 update. It's already enabled in Rawhide.
logwatch-7.3.6-51.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/logwatch-7.3.6-51.fc13
logwatch-7.3.6-51.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/logwatch-7.3.6-51.fc12
logwatch-7.3.6-51.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update logwatch'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/logwatch-7.3.6-51.fc12
logwatch-7.3.6-51.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
logwatch-7.3.6-51.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.