On Mon, 26 Feb 2024, 13:03 Michael Biebl, <bi...@debian.org> wrote: > Hi > > On Thu, 22 Feb 2024 19:01:05 +0000 Richard Lewis > <richard.lewis.deb...@googlemail.com> wrote: > > On Thu, 22 Feb 2024, 10:15 Ralf Schlatterbeck, <r...@runtux.com> 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 and that both timestamp > > > formats are valid RFC 3339 (I've checked, the grammar explicitly > defines > > > the sub-seconds part of the timestamp as optional). See link above. > > > They also think, logcheck should cope with both formats. > > > > > > 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 that? there's a limit to > > how much to suport out of the box - especially as rsyslog is no longer > the > > default. > > Just to clarify: It is correct that rsyslog is no longer installed by > default. That said, I would still consider rsyslog the default syslog > daemon in Debian. Packages that depend on system-log-daemon typically do > this via a "Depends: rsyslog | system-log-daemon" >
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? As for this specific issue, Ralf has found a way to make ensure that > remote syslog messages also carry a subseconds timestamp by explicitly > specifying the format when forwarding the messages [2] > > Michael > > [1] > > https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.36/administration-guide/ts-format > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064385#29 >
