Bug 669758 - logwatch does not show summary of yesterdays backups
logwatch does not show summary of yesterdays backups
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: bacula (Show other bugs)
14
Unspecified Linux
low Severity low
: ---
: ---
Assigned To: Simone Caronni
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-14 11:24 EST by Kurt Neufeld
Modified: 2012-07-19 09:16 EDT (History)
8 users (show)

See Also:
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: ---


Attachments (Terms of Use)
snippet of my log file (6.21 KB, text/plain)
2011-02-09 12:20 EST, Kurt Neufeld
no flags Details

  None (edit)
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):

bacula-director-common-5.0.2-8.fc14.x86_64

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:

Nothing.

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
      BackupOK

 ---------------------- 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
20a21,24
> BEGIN {
>       push @INC, "/usr/share/logwatch/lib";
> }
>
25c29
< $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 
LANG="en_US.UTF-8"
SYSFONT="latarcyrheb-sun16"
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
Hello,

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?

Thanks,
--Simone
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.

Kurt
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.

Thanks,
--Simone

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