Logwatch (randomly) skipping days => Feature!?

Logwatch (randomly) skipping days => Feature!?

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

Hi,

I discovered something weird:

>From time to time 'logwatch' does not create a daily log.

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

The same happened yesterday 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 was created, everything looks ok.

1. Can anyone confirm?

2. With which parameter could I change the starting time "01 0 * * *" so
that this doesn't happen again? I'm searching, but can't find a grip on
this...

Best,
Matthias

Re: Logwatch (randomly) skipping days => Feature!?

[Tapani Tarvainen]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

Hi,

1. Confirmed. Seems to happen randomly about twice a month or so.

2. My first guess of the cause is that as logwatch runs at
   the same time as logrotate it causes a race condition:

# fcrontab -l|grep log
2019-02-17 12:32:01  INFO listing root's fcrontab
01 * * * *      /usr/sbin/logrotate /etc/logrotate.conf
01 0 * * *      /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 '{}' ';'

Try changing the minute value in logwatch to 02 or maybe 03 to be on the safe side.

Incidentally, why is logrotate being run every hour? Wouldn't daily be enough?

Tapani


On Sun, Feb 17, 2019 at 10:22:26AM +0100, Matthias Fischer (matthias.fischer(a)ipfire.org) wrote:
> 
> Hi,
> 
> I discovered something weird:
> 
> >From time to time 'logwatch' does not create a daily log.
> 
> E.g.:
> The file '/var/log/logwatch/2019-14-26' exists, but size = 0 Bytes.
> 
> The same happened yesterday 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 was created, everything looks ok.
> 
> 1. Can anyone confirm?
> 
> 2. With which parameter could I change the starting time "01 0 * * *" so
> that this doesn't happen again? I'm searching, but can't find a grip on
> this...
> 
> Best,
> Matthias

Re: Logwatch (randomly) skipping days => Feature!?

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

Hi,

On 17.02.2019 11:38, Tapani Tarvainen wrote:
> Hi,
> 
> 1. Confirmed. Seems to happen randomly about twice a month or so.

Ok, I'm not alone. ;-)

> 2. My first guess of the cause is that as logwatch runs at
>    the same time as logrotate it causes a race condition:
> 
> # fcrontab -l|grep log
> 2019-02-17 12:32:01  INFO listing root's fcrontab
> 01 * * * *      /usr/sbin/logrotate /etc/logrotate.conf
> 01 0 * * *      /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 '{}' ';'
> 
> Try changing the minute value in logwatch to 02 or maybe 03 to be on the safe side.

Done. Changed to "03". We'll see.

> Incidentally, why is logrotate being run every hour? Wouldn't daily be enough?

No idea. Better granularity?

Best,
Matthias

> 
> Tapani
> 
> 
> On Sun, Feb 17, 2019 at 10:22:26AM +0100, Matthias Fischer (matthias.fischer(a)ipfire.org) wrote:
>> 
>> Hi,
>> 
>> I discovered something weird:
>> 
>> >From time to time 'logwatch' does not create a daily log.
>> 
>> E.g.:
>> The file '/var/log/logwatch/2019-14-26' exists, but size = 0 Bytes.
>> 
>> The same happened yesterday 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 was created, everything looks ok.
>> 
>> 1. Can anyone confirm?
>> 
>> 2. With which parameter could I change the starting time "01 0 * * *" so
>> that this doesn't happen again? I'm searching, but can't find a grip on
>> this...
>> 
>> Best,
>> Matthias
> 

Re: Logwatch (randomly) skipping days => Feature!?

[Tom Rymes]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

Is this a ticking issue where one log has two days’ data and the other is empty?

> On Feb 17, 2019, at 4:22 AM, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> Hi,
> 
> I discovered something weird:
> 
> From time to time 'logwatch' does not create a daily log.
> 
> E.g.:
> The file '/var/log/logwatch/2019-14-26' exists, but size = 0 Bytes.
> 
> The same happened yesterday 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 was created, everything looks ok.
> 
> 1. Can anyone confirm?
> 
> 2. With which parameter could I change the starting time "01 0 * * *" so
> that this doesn't happen again? I'm searching, but can't find a grip on
> this...
> 
> Best,
> Matthias

Re: Logwatch (randomly) skipping days => Feature!?

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 1785 bytes --]

Hi,

On 17.02.2019 15:42, Tom Rymes wrote:
> Is this a ticking issue where one log has two days’ data and the other is empty?

[Correction:
Of course I meant '.../2019-01-26' ;-) ]

Looking an it - could be the case. The log created on 2019-01-28 is
significantly bigger:

***SNIP***
...
-rw-r--r-- 1 root root  43698 Jan 24 00:01 2019-01-23
-rw-r--r-- 1 root root  56469 Jan 25 00:01 2019-01-24
-rw-r--r-- 1 root root  57936 Jan 26 00:01 2019-01-25
-rw-r--r-- 1 root root      0 Jan 27 00:01 2019-01-26
-rw-r--r-- 1 root root 114650 Jan 28 00:01 2019-01-27
-rw-r--r-- 1 root root  40121 Jan 29 00:01 2019-01-28
-rw-r--r-- 1 root root  38220 Jan 30 00:01 2019-01-29
...
***SNAP***

But what can I do about this? For now, I changed running time to
"03 0 * * *".

Best,
Matthias

>> On Feb 17, 2019, at 4:22 AM, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>> 
>> Hi,
>> 
>> I discovered something weird:
>> 
>> From time to time 'logwatch' does not create a daily log.
>> 
>> E.g.:
>> The file '/var/log/logwatch/2019-14-26' exists, but size = 0 Bytes.
>> 
>> The same happened yesterday 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 was created, everything looks ok.
>> 
>> 1. Can anyone confirm?
>> 
>> 2. With which parameter could I change the starting time "01 0 * * *" so
>> that this doesn't happen again? I'm searching, but can't find a grip on
>> this...
>> 
>> Best,
>> Matthias
> 

Re: Logwatch (randomly) skipping days => Feature!?

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]

Hi,

I do not think that you have two reports in the larger file.

In the cronjob line the file is being overwritten (>) and not appended (>>).

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?

-Michael

> On 17 Feb 2019, at 15:01, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> Hi,
> 
> On 17.02.2019 15:42, Tom Rymes wrote:
>> Is this a ticking issue where one log has two days’ data and the other is empty?
> 
> [Correction:
> Of course I meant '.../2019-01-26' ;-) ]
> 
> Looking an it - could be the case. The log created on 2019-01-28 is
> significantly bigger:
> 
> ***SNIP***
> ...
> -rw-r--r-- 1 root root  43698 Jan 24 00:01 2019-01-23
> -rw-r--r-- 1 root root  56469 Jan 25 00:01 2019-01-24
> -rw-r--r-- 1 root root  57936 Jan 26 00:01 2019-01-25
> -rw-r--r-- 1 root root      0 Jan 27 00:01 2019-01-26
> -rw-r--r-- 1 root root 114650 Jan 28 00:01 2019-01-27
> -rw-r--r-- 1 root root  40121 Jan 29 00:01 2019-01-28
> -rw-r--r-- 1 root root  38220 Jan 30 00:01 2019-01-29
> ...
> ***SNAP***
> 
> But what can I do about this? For now, I changed running time to
> "03 0 * * *".
> 
> Best,
> Matthias
> 
>>> On Feb 17, 2019, at 4:22 AM, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>> 
>>> Hi,
>>> 
>>> I discovered something weird:
>>> 
>>> From time to time 'logwatch' does not create a daily log.
>>> 
>>> E.g.:
>>> The file '/var/log/logwatch/2019-14-26' exists, but size = 0 Bytes.
>>> 
>>> The same happened yesterday 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 was created, everything looks ok.
>>> 
>>> 1. Can anyone confirm?
>>> 
>>> 2. With which parameter could I change the starting time "01 0 * * *" so
>>> that this doesn't happen again? I'm searching, but can't find a grip on
>>> this...
>>> 
>>> Best,
>>> Matthias
>> 
> 

Re: Logwatch (randomly) skipping days => Feature!?

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 2602 bytes --]

Hi,

On 18.02.2019 13:38, Michael Tremer wrote:
> Hi,
> 
> I do not think that you have two reports in the larger file.
> 
> In the cronjob line the file is being overwritten (>) and not appended (>>).

I see.

> 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?

This was my first suspicion. After changing the start time of the
'logwatch'-job the error did not occur again until now. I'll wait and watch.

Best,
Matthias

> -Michael
> 
>> On 17 Feb 2019, at 15:01, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>> 
>> Hi,
>> 
>> On 17.02.2019 15:42, Tom Rymes wrote:
>>> Is this a ticking issue where one log has two days’ data and the other is empty?
>> 
>> [Correction:
>> Of course I meant '.../2019-01-26' ;-) ]
>> 
>> Looking an it - could be the case. The log created on 2019-01-28 is
>> significantly bigger:
>> 
>> ***SNIP***
>> ...
>> -rw-r--r-- 1 root root  43698 Jan 24 00:01 2019-01-23
>> -rw-r--r-- 1 root root  56469 Jan 25 00:01 2019-01-24
>> -rw-r--r-- 1 root root  57936 Jan 26 00:01 2019-01-25
>> -rw-r--r-- 1 root root      0 Jan 27 00:01 2019-01-26
>> -rw-r--r-- 1 root root 114650 Jan 28 00:01 2019-01-27
>> -rw-r--r-- 1 root root  40121 Jan 29 00:01 2019-01-28
>> -rw-r--r-- 1 root root  38220 Jan 30 00:01 2019-01-29
>> ...
>> ***SNAP***
>> 
>> But what can I do about this? For now, I changed running time to
>> "03 0 * * *".
>> 
>> Best,
>> Matthias
>> 
>>>> On Feb 17, 2019, at 4:22 AM, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I discovered something weird:
>>>> 
>>>> From time to time 'logwatch' does not create a daily log.
>>>> 
>>>> E.g.:
>>>> The file '/var/log/logwatch/2019-14-26' exists, but size = 0 Bytes.
>>>> 
>>>> The same happened yesterday 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 was created, everything looks ok.
>>>> 
>>>> 1. Can anyone confirm?
>>>> 
>>>> 2. With which parameter could I change the starting time "01 0 * * *" so
>>>> that this doesn't happen again? I'm searching, but can't find a grip on
>>>> this...
>>>> 
>>>> Best,
>>>> Matthias
>>> 
>> 
> 
> 

Re: Logwatch (randomly) skipping days => Feature!?

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3031 bytes --]

Cool.

I think logwatch might require to be started on the top of the hour.

But for logrotate it doesn’t matter much and I think we probably should run it a bit more often anyways. Maybe every 15 minutes or so...

-Michael 

> On 18 Feb 2019, at 13:14, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> Hi,
> 
> On 18.02.2019 13:38, Michael Tremer wrote:
>> Hi,
>> 
>> I do not think that you have two reports in the larger file.
>> 
>> In the cronjob line the file is being overwritten (>) and not appended (>>).
> 
> I see.
> 
>> 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?
> 
> This was my first suspicion. After changing the start time of the
> 'logwatch'-job the error did not occur again until now. I'll wait and watch.
> 
> Best,
> Matthias
> 
>> -Michael
>> 
>>> On 17 Feb 2019, at 15:01, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>> 
>>> Hi,
>>> 
>>> On 17.02.2019 15:42, Tom Rymes wrote:
>>>> Is this a ticking issue where one log has two days’ data and the other is empty?
>>> 
>>> [Correction:
>>> Of course I meant '.../2019-01-26' ;-) ]
>>> 
>>> Looking an it - could be the case. The log created on 2019-01-28 is
>>> significantly bigger:
>>> 
>>> ***SNIP***
>>> ...
>>> -rw-r--r-- 1 root root  43698 Jan 24 00:01 2019-01-23
>>> -rw-r--r-- 1 root root  56469 Jan 25 00:01 2019-01-24
>>> -rw-r--r-- 1 root root  57936 Jan 26 00:01 2019-01-25
>>> -rw-r--r-- 1 root root      0 Jan 27 00:01 2019-01-26
>>> -rw-r--r-- 1 root root 114650 Jan 28 00:01 2019-01-27
>>> -rw-r--r-- 1 root root  40121 Jan 29 00:01 2019-01-28
>>> -rw-r--r-- 1 root root  38220 Jan 30 00:01 2019-01-29
>>> ...
>>> ***SNAP***
>>> 
>>> But what can I do about this? For now, I changed running time to
>>> "03 0 * * *".
>>> 
>>> Best,
>>> Matthias
>>> 
>>>>> On Feb 17, 2019, at 4:22 AM, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I discovered something weird:
>>>>> 
>>>>> From time to time 'logwatch' does not create a daily log.
>>>>> 
>>>>> E.g.:
>>>>> The file '/var/log/logwatch/2019-14-26' exists, but size = 0 Bytes.
>>>>> 
>>>>> The same happened yesterday 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 was created, everything looks ok.
>>>>> 
>>>>> 1. Can anyone confirm?
>>>>> 
>>>>> 2. With which parameter could I change the starting time "01 0 * * *" so
>>>>> that this doesn't happen again? I'm searching, but can't find a grip on
>>>>> this...
>>>>> 
>>>>> Best,
>>>>> Matthias
>>>> 
>>> 
>> 
>> 
> 

Re: Logwatch (randomly) skipping days => Feature!?

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 3111 bytes --]

Hi,

For testing, I changed the conjob for logwatch from 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."

So it took some time, but the bug still exists.

Any suggestions? I think, I should open a bug report...

Best,
Matthias

On 18.02.2019 14:14, Matthias Fischer wrote:
> Hi,
> 
> On 18.02.2019 13:38, Michael Tremer wrote:
>> Hi,
>> 
>> I do not think that you have two reports in the larger file.
>> 
>> In the cronjob line the file is being overwritten (>) and not appended (>>).
> 
> I see.
> 
>> 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?
> 
> This was my first suspicion. After changing the start time of the
> 'logwatch'-job the error did not occur again until now. I'll wait and watch.
> 
> Best,
> Matthias
> 
>> -Michael
>> 
>>> On 17 Feb 2019, at 15:01, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>> 
>>> Hi,
>>> 
>>> On 17.02.2019 15:42, Tom Rymes wrote:
>>>> Is this a ticking issue where one log has two days’ data and the other is empty?
>>> 
>>> [Correction:
>>> Of course I meant '.../2019-01-26' ;-) ]
>>> 
>>> Looking an it - could be the case. The log created on 2019-01-28 is
>>> significantly bigger:
>>> 
>>> ***SNIP***
>>> ...
>>> -rw-r--r-- 1 root root  43698 Jan 24 00:01 2019-01-23
>>> -rw-r--r-- 1 root root  56469 Jan 25 00:01 2019-01-24
>>> -rw-r--r-- 1 root root  57936 Jan 26 00:01 2019-01-25
>>> -rw-r--r-- 1 root root      0 Jan 27 00:01 2019-01-26
>>> -rw-r--r-- 1 root root 114650 Jan 28 00:01 2019-01-27
>>> -rw-r--r-- 1 root root  40121 Jan 29 00:01 2019-01-28
>>> -rw-r--r-- 1 root root  38220 Jan 30 00:01 2019-01-29
>>> ...
>>> ***SNAP***
>>> 
>>> But what can I do about this? For now, I changed running time to
>>> "03 0 * * *".
>>> 
>>> Best,
>>> Matthias
>>> 
>>>>> On Feb 17, 2019, at 4:22 AM, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I discovered something weird:
>>>>> 
>>>>> From time to time 'logwatch' does not create a daily log.
>>>>> 
>>>>> E.g.:
>>>>> The file '/var/log/logwatch/2019-14-26' exists, but size = 0 Bytes.
>>>>> 
>>>>> The same happened yesterday 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 was created, everything looks ok.
>>>>> 
>>>>> 1. Can anyone confirm?
>>>>> 
>>>>> 2. With which parameter could I change the starting time "01 0 * * *" so
>>>>> that this doesn't happen again? I'm searching, but can't find a grip on
>>>>> this...
>>>>> 
>>>>> Best,
>>>>> Matthias
>>>> 
>>> 
>> 
>> 
> 
> 

Re: Logwatch (randomly) skipping days => Feature!?

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3415 bytes --]

Hi,

Yes, please open a bug report and we will take it from there.

Best,
-Michael

> On 1 Apr 2019, at 17:28, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> Hi,
> 
> For testing, I changed the conjob for logwatch from 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."
> 
> So it took some time, but the bug still exists.
> 
> Any suggestions? I think, I should open a bug report...
> 
> Best,
> Matthias
> 
> On 18.02.2019 14:14, Matthias Fischer wrote:
>> Hi,
>> 
>> On 18.02.2019 13:38, Michael Tremer wrote:
>>> Hi,
>>> 
>>> I do not think that you have two reports in the larger file.
>>> 
>>> In the cronjob line the file is being overwritten (>) and not appended (>>).
>> 
>> I see.
>> 
>>> 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?
>> 
>> This was my first suspicion. After changing the start time of the
>> 'logwatch'-job the error did not occur again until now. I'll wait and watch.
>> 
>> Best,
>> Matthias
>> 
>>> -Michael
>>> 
>>>> On 17 Feb 2019, at 15:01, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> On 17.02.2019 15:42, Tom Rymes wrote:
>>>>> Is this a ticking issue where one log has two days’ data and the other is empty?
>>>> 
>>>> [Correction:
>>>> Of course I meant '.../2019-01-26' ;-) ]
>>>> 
>>>> Looking an it - could be the case. The log created on 2019-01-28 is
>>>> significantly bigger:
>>>> 
>>>> ***SNIP***
>>>> ...
>>>> -rw-r--r-- 1 root root  43698 Jan 24 00:01 2019-01-23
>>>> -rw-r--r-- 1 root root  56469 Jan 25 00:01 2019-01-24
>>>> -rw-r--r-- 1 root root  57936 Jan 26 00:01 2019-01-25
>>>> -rw-r--r-- 1 root root      0 Jan 27 00:01 2019-01-26
>>>> -rw-r--r-- 1 root root 114650 Jan 28 00:01 2019-01-27
>>>> -rw-r--r-- 1 root root  40121 Jan 29 00:01 2019-01-28
>>>> -rw-r--r-- 1 root root  38220 Jan 30 00:01 2019-01-29
>>>> ...
>>>> ***SNAP***
>>>> 
>>>> But what can I do about this? For now, I changed running time to
>>>> "03 0 * * *".
>>>> 
>>>> Best,
>>>> Matthias
>>>> 
>>>>>> On Feb 17, 2019, at 4:22 AM, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I discovered something weird:
>>>>>> 
>>>>>> From time to time 'logwatch' does not create a daily log.
>>>>>> 
>>>>>> E.g.:
>>>>>> The file '/var/log/logwatch/2019-14-26' exists, but size = 0 Bytes.
>>>>>> 
>>>>>> The same happened yesterday 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 was created, everything looks ok.
>>>>>> 
>>>>>> 1. Can anyone confirm?
>>>>>> 
>>>>>> 2. With which parameter could I change the starting time "01 0 * * *" so
>>>>>> that this doesn't happen again? I'm searching, but can't find a grip on
>>>>>> this...
>>>>>> 
>>>>>> Best,
>>>>>> Matthias
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 

Re: Logwatch (randomly) skipping days => Feature!?

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 3624 bytes --]

Hi,

Done.

=> https://bugzilla.ipfire.org/show_bug.cgi?id=12036

Best,
Matthias

On 01.04.2019 18:34, Michael Tremer wrote:
> Hi,
> 
> Yes, please open a bug report and we will take it from there.
> 
> Best,
> -Michael
> 
>> On 1 Apr 2019, at 17:28, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>> 
>> Hi,
>> 
>> For testing, I changed the conjob for logwatch from 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."
>> 
>> So it took some time, but the bug still exists.
>> 
>> Any suggestions? I think, I should open a bug report...
>> 
>> Best,
>> Matthias
>> 
>> On 18.02.2019 14:14, Matthias Fischer wrote:
>>> Hi,
>>> 
>>> On 18.02.2019 13:38, Michael Tremer wrote:
>>>> Hi,
>>>> 
>>>> I do not think that you have two reports in the larger file.
>>>> 
>>>> In the cronjob line the file is being overwritten (>) and not appended (>>).
>>> 
>>> I see.
>>> 
>>>> 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?
>>> 
>>> This was my first suspicion. After changing the start time of the
>>> 'logwatch'-job the error did not occur again until now. I'll wait and watch.
>>> 
>>> Best,
>>> Matthias
>>> 
>>>> -Michael
>>>> 
>>>>> On 17 Feb 2019, at 15:01, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> On 17.02.2019 15:42, Tom Rymes wrote:
>>>>>> Is this a ticking issue where one log has two days’ data and the other is empty?
>>>>> 
>>>>> [Correction:
>>>>> Of course I meant '.../2019-01-26' ;-) ]
>>>>> 
>>>>> Looking an it - could be the case. The log created on 2019-01-28 is
>>>>> significantly bigger:
>>>>> 
>>>>> ***SNIP***
>>>>> ...
>>>>> -rw-r--r-- 1 root root  43698 Jan 24 00:01 2019-01-23
>>>>> -rw-r--r-- 1 root root  56469 Jan 25 00:01 2019-01-24
>>>>> -rw-r--r-- 1 root root  57936 Jan 26 00:01 2019-01-25
>>>>> -rw-r--r-- 1 root root      0 Jan 27 00:01 2019-01-26
>>>>> -rw-r--r-- 1 root root 114650 Jan 28 00:01 2019-01-27
>>>>> -rw-r--r-- 1 root root  40121 Jan 29 00:01 2019-01-28
>>>>> -rw-r--r-- 1 root root  38220 Jan 30 00:01 2019-01-29
>>>>> ...
>>>>> ***SNAP***
>>>>> 
>>>>> But what can I do about this? For now, I changed running time to
>>>>> "03 0 * * *".
>>>>> 
>>>>> Best,
>>>>> Matthias
>>>>> 
>>>>>>> On Feb 17, 2019, at 4:22 AM, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I discovered something weird:
>>>>>>> 
>>>>>>> From time to time 'logwatch' does not create a daily log.
>>>>>>> 
>>>>>>> E.g.:
>>>>>>> The file '/var/log/logwatch/2019-14-26' exists, but size = 0 Bytes.
>>>>>>> 
>>>>>>> The same happened yesterday 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 was created, everything looks ok.
>>>>>>> 
>>>>>>> 1. Can anyone confirm?
>>>>>>> 
>>>>>>> 2. With which parameter could I change the starting time "01 0 * * *" so
>>>>>>> that this doesn't happen again? I'm searching, but can't find a grip on
>>>>>>> this...
>>>>>>> 
>>>>>>> Best,
>>>>>>> Matthias