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

[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:
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:
2024-02-16T22:06:02+01:00 tux1 [...]

Logcheck currently deals only with the first format. This results in no
logcheck pattern matching for remote host log entries.

Fortunately logcheck also still supports the 'traditional' format which I've
reverted to.

I would expect rsyslog to only use a single format, but failing that I think
that logcheck should not drop support for the old 'traditional' timestamp
format until the issue in rsyslogd is resolved.

Logcheck *may* want to support both rfc3339 formats (the sub-seconds part *is*
optional in the RFC).


-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages logcheck depends on:
ii adduser 3.134
ii cron [cron-daemon] 3.0pl1-162
ii lockfile-progs 0.1.19
ii logtail 1.4.2
ii mime-construct 1.12+really1.11-1
ii postfix [mail-transport-agent] 3.7.10-0+deb12u1

Versions of packages logcheck recommends:
ii logcheck-database 1.4.2

Versions of packages logcheck suggests:
ii rsyslog [system-log-daemon] 8.2302.0-1

-- Configuration Files:
/etc/logcheck/logcheck.logfiles changed [not included]

-- no debconf information

[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:
> 2024-02-16T22:06:02+01:00 tux1 [...]
>
> Logcheck currently deals only with the first format. This results in no
> logcheck pattern matching for remote host log entries.

I forgot to mention:
There is an upstream (rsyslog) bug-report at
https://github.com/rsyslog/rsyslog/issues/5332

And a debian bug report for rsyslog at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064385

Thanks
Ralf
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting www: www.runtux.com
Reichergasse 131, A-3411 Weidling email: off...@runtux.com

[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, 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).

In the downstream bug-report of rsylogd (which I suppose will be closed
soon) I've mentioned how to configure remote clients to send a timestamp
*with* sub-seconds part.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064385

But there may be other clients out there (which may not be rsyslogd)
which still send the traditional format and thus will be logged without
a subseconds part.

So logcheck should be prepared to receive both formats.