#1135633 logcheck: Logcheck filters can't handle multi-line logs from systemd-journal

#1135633#5
Date:
2026-05-03 19:21:17 UTC
From:
To:
Dear Maintainer,

Logcheck filters always operate on one single line, yet multi-line logs are
possible (at least with systemd-journal, not sure about syslog). This breaks
logchecks filtering and the corresponding e-mail reports will contain partial
logs.

As an example, opendmarc creates log entries like these:
                                                 spf=pass (google.com: domain of 3cgimarqkaacnvvnslhsly0z-uvylws5nvvnsl.jvt@alerts.bounces.google.com designates 209.85.220.69 as permitted sender) smt>
                                                 dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com;
                                                 dara=pass header.i=@gmail.com"
---

One solution is to write separate filters for all of these lines but that's
not always a good idea.

I would propose the following solution:

This problem could be rectified by a different kind processing of the
journalctl output. The following will replace all newlines in a log by a
space but otherwise produce the same output format as a normal call to
journalctl. (admittedly it's a quick hack, maybe could use some more
refinement...)

journalctl -o json | jq -r '
                   def ts:
                     (.__REALTIME_TIMESTAMP | tonumber / 1000000 | strftime("%b %d %H:%M:%S"));

                   "\(ts) \(._HOSTNAME // "-") \(.SYSLOG_IDENTIFIER // "unknown")[\(._PID // "-")]: \((.MESSAGE // "") | gsub("\n"; " "))"


This will add a dependency to jq. It will also definitely processing time,
but should be negligible.

Best regards,
Klaus

#1135633#10
Date:
2026-05-03 21:33:01 UTC
From:
To:
i dont think sysslog supports this, but logcheck can process any logs,
and eg mail logs have the same issue
journalctl customisable and this will make that harder

Instead we should generalise the code that strips trailing spaces to
make lines starting with a space are joined to the previous one. This
can be done with sed - i've been playing with having an array of
pre-processors, and it looks good so far (my one concern is if people
will want different processing per log-file, which would need more
work)

PRE_PROCESS_LOG_ENTRIES=(
 "sed -e ':a;N;s/\n[[:space:]]\+//;ta;P;D'"
 "sed -e 's/[[:space:]]\+$//'"
)

and have this separate to (and before) the $SORT

#1135633#15
Date:
2026-05-03 22:10:04 UTC
From:
To:
Oh, I’m happy with any solution that solves this problem. The one I mentioned was just the first one that came to my mind… :-)

Thanks for the quick feedback,
 Klaus