Bug 669758

Summary: logwatch does not show summary of yesterdays backups
Product: [Fedora] Fedora Reporter: Kurt Neufeld <kneufeld>
Component: baculaAssignee: Simone Caronni <negativo17>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 14CC: andreas, dnovotny, fschwarz, jgorig, limburgher, mmcgrath, negativo17, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-07-19 09:16:38 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
snippet of my log file none

Description Kurt Neufeld 2011-01-14 11:24:39 EST
Description of problem:

Even though the bacula scripts are installed in the logwatch directories, the mornings logwatch report has no summary of the backup jobs that were run.

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


How reproducible:

Every morning.

Steps to Reproduce:
1. Run a bacula backup job
2. Wait until the next day (or change clock)
3. Run logwatch
Actual results:


Expected results:

A summary in logwatch. Something like the following:

 --------------------- bacula Begin ------------------------

 Jobs Run:
 2011-01-13 193 magneto-mysql.2011-01-13_03.00.00_38

 ---------------------- bacula End -------------------------

Additional info:

There were two problems that I could tell. The first being that applybaculadate failed to run because it couldn't find Locate.pm. The second being the date format passed into TimeFIlter doesn't match the date format in the log file.

Here's a patch for /etc/logwatch/scripts/shared/applybaculadate

# diff applybaculadate.orig applybaculadate
>       push @INC, "/usr/share/logwatch/lib";
> }
< $SearchDate = TimeFilter('%d-%b %H:%M');
> $SearchDate = TimeFilter('%Y-%m-%d');
Comment 1 Jan Görig 2011-02-01 08:40:49 EST
Missing path isn't issue because applybaculadate is loaded from logwatch.pl. It doesn't need to be runnable itself. None of logwatch scripts has defined additional include directory.

This problem is actually caused by locale settings on non English systems. Time filtering runs on log file that is in '%d-%b %H:%M' format, so applybaculadate is correct.
Problem is that bacula-dir which creates log file runs on system locale and logwatch forces LC_ALL=C. This causes different month name and time doesn't match.

The best approach is probably modify bacula to use month in decimal number format.

Temporary workaround is running bacula-dir with LC_ALL=C.
Comment 2 Kurt Neufeld 2011-02-01 22:01:17 EST
My locale is English though...

# cat /etc/sysconfig/i18n 
Comment 3 Jan Görig 2011-02-09 06:39:21 EST
Could you send me fragment of /var/spool/bacula/log or /var/log/bacula.log, please? Thanks.
Comment 4 Kurt Neufeld 2011-02-09 12:20:16 EST
Created attachment 477868 [details]
snippet of my log file
Comment 5 Jan Görig 2011-02-10 05:43:04 EST
After some investigation in source code I found that this is more complicated...

Almost all log messages uses date format I wrote above. Problem is that output to catalog uses different format and there is an another bug in bacula.

If you have catalog directive in Message resource in bacula-dir.conf, all messages which are send to destinations that are defined after this directive will be displayed incorrectly with catalog date format.

This bug requires more steps to be fixed so I will discuss this issue with upstream.

Temporary workaround for you should be move catalog directive to the end of Message resource.
Comment 6 Simone Caronni 2012-07-18 05:34:48 EDT

I'm doing some housekeeping in Bacula bugs, can you confirm the problem is still relevant with the latest packages in one of f16, f17 or rawhide?

Comment 7 Kurt Neufeld 2012-07-18 09:22:04 EDT
I'm afraid I can't confirm or deny the problem as I haven't been running Bacula for almost a year now.

Comment 8 Simone Caronni 2012-07-19 09:16:38 EDT
The bug has been opened for a year and a half, I'm closing this down, please reopen if it still happens with more recent packages that are very different from the one listed here.