From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Fischer <matthias.fischer@ipfire.org> To: development@lists.ipfire.org Subject: Re: Logwatch (randomly) skipping days => Feature!? Date: Mon, 01 Apr 2019 18:48:27 +0200 Message-ID: <32ed52f1-5924-b323-2c48-fdd513b84fd3@ipfire.org> In-Reply-To: <64418930-EF66-4168-B165-6097E60E25DF@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0165353433345480579==" List-Id: <development.lists.ipfire.org> --===============0165353433345480579== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Done. =3D> https://bugzilla.ipfire.org/show_bug.cgi?id=3D12036 Best, Matthias On 01.04.2019 18:34, Michael Tremer wrote: > Hi, >=20 > Yes, please open a bug report and we will take it from there. >=20 > Best, > -Michael >=20 >> On 1 Apr 2019, at 17:28, Matthias Fischer <matthias.fischer(a)ipfire.org> = wrote: >>=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 launch= ed at the same time and logwatch tries to read files that are being rotated a= way? >>>=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 wat= ch. >>>=20 >>> Best, >>> Matthias >>>=20 >>>> -Michael >>>>=20 >>>>> On 17 Feb 2019, at 15:01, Matthias Fischer <matthias.fischer(a)ipfire.o= rg> 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 t= he 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 <matthias.fischer(a)ipf= ire.org> 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 --===============0165353433345480579==--