Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version

2024-02-27 Thread Ralf Schlatterbeck
On Tue, Feb 27, 2024 at 08:50:48AM +, Richard Lewis wrote: > thanks - agree logcheck should cope with a default rsyslog output. ... i > just dont know what that default output is: does the below mean the > subseconds are now always present? > > or: what regexp should logcheck use as prefix?

Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version

2024-02-27 Thread Michael Biebl
Am 27.02.24 um 09:50 schrieb Richard Lewis: thanks - agree logcheck should cope with a default rsyslog output. ... i just dont know what that default output is: does the below mean the subseconds are now always present? For locally generated messages, the time stamp includes subsecond

Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version

2024-02-27 Thread Richard Lewis
On Mon, 26 Feb 2024, 13:03 Michael Biebl, wrote: > Hi > > On Thu, 22 Feb 2024 19:01:05 + Richard Lewis > wrote: > > On Thu, 22 Feb 2024, 10:15 Ralf Schlatterbeck, wrote: > > > > > On Wed, Feb 21, 2024 at 02:52:33PM +0100, Ralf Schlatterbeck wrote: > > > > > > > > I forgot to mention: > > >

Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version

2024-02-26 Thread Michael Biebl
Hi On Thu, 22 Feb 2024 19:01:05 + Richard Lewis wrote: On Thu, 22 Feb 2024, 10:15 Ralf Schlatterbeck, wrote: > On Wed, Feb 21, 2024 at 02:52:33PM +0100, Ralf Schlatterbeck wrote: > > > > I forgot to mention: > > There is an upstream (rsyslog) bug-report at > >

Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version

2024-02-22 Thread Ralf Schlatterbeck
On Thu, Feb 22, 2024 at 07:01:05PM +, Richard Lewis wrote: > > > > So I guess that logcheck should be prepared to receive both kinds of > > timestamps, the 32-byte version and the 25-byte version (without the > > subseconds timestamp). > > what is the default, and does logcheck cope with

Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version

2024-02-22 Thread Richard Lewis
On Thu, 22 Feb 2024, 10:15 Ralf Schlatterbeck, wrote: > On Wed, Feb 21, 2024 at 02:52:33PM +0100, Ralf Schlatterbeck wrote: > > > > I forgot to mention: > > There is an upstream (rsyslog) bug-report at > > https://github.com/rsyslog/rsyslog/issues/5332 > > Upstream has decided that it is not a

Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version

2024-02-22 Thread Ralf Schlatterbeck
On Wed, Feb 21, 2024 at 02:52:33PM +0100, Ralf Schlatterbeck wrote: > > I forgot to mention: > There is an upstream (rsyslog) bug-report at > https://github.com/rsyslog/rsyslog/issues/5332 Upstream has decided that it is not a bug and that both timestamp formats are valid RFC 3339 (I've checked,

Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version

2024-02-21 Thread Ralf Schlatterbeck
On Wed, Feb 21, 2024 at 02:24:03PM +0100, Ralf Schlatterbeck wrote: > > Local log lines include the sub-seconds part like: > 2024-02-16T22:05:52.315463+01:00 tux [...] > > while remote logs (in that case from virtual machines on the same host) do not > include the sub-seconds part: >

Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version

2024-02-21 Thread Ralf Schlatterbeck
Package: logcheck Version: 1.4.2 Severity: normal Dear Maintainer, rsyslogd currently produces two different timestamp formats at the start of a log line with the default (now also Debian default) rfc3339 format. Local log lines include the sub-seconds part like: