Bug 669758 - logwatch does not show summary of yesterdays backups
Summary: logwatch does not show summary of yesterdays backups
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: bacula
Version: 14
Hardware: Unspecified
OS: Linux
low
low
Target Milestone: ---
Assignee: Simone Caronni
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-14 16:24 UTC by Kurt Neufeld
Modified: 2012-07-19 13:16 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-19 13:16:38 UTC
Type: ---
Embargoed:


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

Description Kurt Neufeld 2011-01-14 16:24:39 UTC
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 13:40:49 UTC
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-02 03:01:17 UTC
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 11:39:21 UTC
Could you send me fragment of /var/spool/bacula/log or /var/log/bacula.log, please? Thanks.

Comment 4 Kurt Neufeld 2011-02-09 17:20:16 UTC
Created attachment 477868 [details]
snippet of my log file

Comment 5 Jan Görig 2011-02-10 10:43:04 UTC
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 09:34:48 UTC
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 13:22:04 UTC
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 13:16:38 UTC
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.