From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Logwatch (randomly) skipping days => Feature!? Date: Mon, 01 Apr 2019 17:34:26 +0100 Message-ID: <64418930-EF66-4168-B165-6097E60E25DF@ipfire.org> In-Reply-To: <5aedb6d5-5944-09eb-3e67-784e4ff40cca@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5319164959234516653==" List-Id: --===============5319164959234516653== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 w= rote: >=20 > Hi, >=20 > For testing, I changed the conjob for logwatch from to "03 0 * * * " but > tonight 'logwatch' did it again: >=20 > "No (or only partial) logs exist for the day queried: > /var/log/logwatch/2019-03-31 could not be opened." >=20 > So it took some time, but the bug still exists. >=20 > Any suggestions? I think, I should open a bug report... >=20 > Best, > Matthias >=20 > On 18.02.2019 14:14, Matthias Fischer wrote: >> Hi, >>=20 >> On 18.02.2019 13:38, Michael Tremer wrote: >>> Hi, >>>=20 >>> I do not think that you have two reports in the larger file. >>>=20 >>> In the cronjob line the file is being overwritten (>) and not appended (>= >). >>=20 >> I see. >>=20 >>> Is it possible that this conflicts with the logrotate job that is launche= d at the same time and logwatch tries to read files that are being rotated aw= ay? >>=20 >> 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 watc= h. >>=20 >> Best, >> Matthias >>=20 >>> -Michael >>>=20 >>>> On 17 Feb 2019, at 15:01, Matthias Fischer wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> On 17.02.2019 15:42, Tom Rymes wrote: >>>>> Is this a ticking issue where one log has two days=E2=80=99 data and th= e other is empty? >>>>=20 >>>> [Correction: >>>> Of course I meant '.../2019-01-26' ;-) ] >>>>=20 >>>> Looking an it - could be the case. The log created on 2019-01-28 is >>>> significantly bigger: >>>>=20 >>>> ***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*** >>>>=20 >>>> But what can I do about this? For now, I changed running time to >>>> "03 0 * * *". >>>>=20 >>>> Best, >>>> Matthias >>>>=20 >>>>>> On Feb 17, 2019, at 4:22 AM, Matthias Fischer wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I discovered something weird: >>>>>>=20 >>>>>> From time to time 'logwatch' does not create a daily log. >>>>>>=20 >>>>>> E.g.: >>>>>> The file '/var/log/logwatch/2019-14-26' exists, but size =3D 0 Bytes. >>>>>>=20 >>>>>> The same happened yesterday with '/var/log/logwatch/2019-02-16': >>>>>> 0 Bytes. >>>>>>=20 >>>>>> After running... >>>>>>=20 >>>>>> /usr/local/bin/logwatch > /var/log/logwatch/`date -I -d yesterday`; \ >>>>>> LOGWATCH_KEEP=3D$(sed -ne 's/^LOGWATCH_KEEP=3D\([0-9]\+\)$/\1/p' >>>>>> /var/ipfire/logging/settings); \ >>>>>> find /var/log/logwatch/ -ctime +${LOGWATCH_KEEP=3D56} -exec rm -f '{}'= ';' >>>>>>=20 >>>>>> ...manually from console, file was created, everything looks ok. >>>>>>=20 >>>>>> 1. Can anyone confirm? >>>>>>=20 >>>>>> 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... >>>>>>=20 >>>>>> Best, >>>>>> Matthias >>>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 --===============5319164959234516653==--