Bug 12036 - 'logwatch' fails to write daily log
Summary: 'logwatch' fails to write daily log
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all Linux
: - Unknown - Minor Usability
Assignee: Matthias Fischer
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-01 17:47 UTC by Matthias Fischer
Modified: 2019-10-17 18:42 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Fischer 2019-04-01 17:47:38 UTC 
Hi,

every once in a while 'logwatch' does not create a daily log.

E.g.:
The file '/var/log/logwatch/2019-01-26' exists, but size = 0 Bytes.

The same happened in February with '/var/log/logwatch/2019-02-16':
0 Bytes.

After running...

/usr/local/bin/logwatch > /var/log/logwatch/`date -I -d yesterday`; \
LOGWATCH_KEEP=$(sed -ne 's/^LOGWATCH_KEEP=\([0-9]\+\)$/\1/p'
/var/ipfire/logging/settings); \
find /var/log/logwatch/ -ctime +${LOGWATCH_KEEP=56} -exec rm -f '{}' ';'

...manually from console, file is created, everything looks ok.

For testing, I changed the conjob for logwatch from "01 0 * * *"
to "03 0 * * *" but tonight 'logwatch' did it again:

"No (or only partial) logs exist for the day queried:
/var/log/logwatch/2019-03-31 could not be opened."

Best,
Matthias
Comment 1 Michael Tremer 2019-04-02 10:25:35 UTC 
Can you enable cron logging when it calls this command?
Comment 2 Matthias Fischer 2019-04-03 08:12:14 UTC 
Is there a way to enable cron logging ONLY for this specific 'logwatch' command?

I only know how to enable cron logging completely and this leads to a whole lot of entries in the log...
Comment 3 Michael Tremer 2019-04-04 10:49:04 UTC 
(In reply to Matthias Fischer from comment #2)
> Is there a way to enable cron logging ONLY for this specific 'logwatch'
> command?
> 
> I only know how to enable cron logging completely and this leads to a whole
> lot of entries in the log...

No, it is either on or off. And yeah, we have jobs that launch every minute :)
Comment 4 Matthias Fischer 2019-08-17 10:18:39 UTC 
FYI:

I changed the conjob for logwatch from "01 0 * * *" to "04 0 * * *".

The system is now running: "Up: 42 days, 16:36"

Problem didn't show up again.

Best,
Matthias
Comment 5 Michael Tremer 2019-08-20 19:15:01 UTC 
So why does 4am work, but 3am does not?
Comment 6 Matthias Fischer 2019-08-23 17:04:54 UTC 
On 20.08.2019 20:15, IPFire Bugzilla wrote:
> https://bugzilla.ipfire.org/show_bug.cgi?id=12036
> 
> --- Comment #5 from Michael Tremer <michael.tremer@ipfire.org> ---
> So why does 4am work, but 3am does not?
> 

I have no (solid) reason, sorry.

The only reason I can think of is - as you wrote earlier
(development-list, 01.04.2019, Re: Logwatch (randomly) skipping days =>
Feature!?):

"Is it possible that this conflicts with the logrotate job that is
launched at the same time and logwatch tries to read files that are
being rotated away?"

After the last ~45 days I would say: yes...

Sorry, I have no more than that right now.

Only thing I can think of could be to change starting time back to "01 0
* * *" and turn on cron logging. Hadn't the nerve to do this yet and
look for the logs each day...

Best,
Matthias
Comment 7 Michael Tremer 2019-08-26 13:53:23 UTC 
Hmm, okay. But shouldn't it be enough then to run logwatch a couple of minutes after midnight? Logrotate should not take longer than 5 minutes - and that only when it has to compress a really really really large file.
Comment 8 Matthias Fischer 2019-08-26 17:02:06 UTC 
Yep.

Thats exactly what I was trying to achieve:

I changed the start of 'logwatch' from "one minute after midnight" to "4 minutes after midnight".

We can alter this to five minutes but I wouldn't go any further.

Or did I miss something?
Comment 9 Michael Tremer 2019-08-28 13:35:05 UTC 
Okay, can you send a patch?