Description of problem: Broken date format after rsyslog update to rsyslog-8.2204.0-1.fc35.x86_64. And no errors in Fedora 36 Version-Release number of selected component (if applicable): Kernel 5.17.5-200.fc35.x86_64 #1 SMP PREEMPT Thu Apr 28 15:41:41 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux Tried on few systems. How reproducible: update rsyslog from rsyslog-8.2102.0-4.fc35.x86_64 to rsyslog-8.2204.0-1.fc35.x86_64 Steps to Reproduce: 1. def update rsyslog Actual results: 2022-05-19T23:29:39.517654+03:00 router systemd[1]: Starting Hostname Service... 2022-05-19T23:29:39.579336+03:00 router systemd[1]: Started Hostname Service. 2022-05-19T23:30:09.605759+03:00 router systemd[1]: systemd-hostnamed.service: Deactivated successfully. Expected results: May 19 22:53:34 router systemd[1]: Starting Hostname Service... May 19 22:53:34 router systemd[1]: Started Hostname Service. May 19 22:54:04 router systemd[1]: systemd-hostnamed.service: Deactivated successfully. Additional info:
Hello, This was accidentally introduced by a recent change. Do you have some practical problems produced by this change? The problem can be resolved by specifying the default template when loading the omfile(or any other output) module, e.g.: module(load="builtin:omfile" Template="RSYSLOG_TraditionalFileFormat")
Changing log file format in the middle of a release and without any announcement or going through the Fedora change process is not good, so it should have been undone as soon as practical. But practically speaking - when I need to look at the logs, the new format is much more difficult to read. It's a longer string (so takes up more screen real estate), but more importantly, it has no spaces, which it makes it more difficult for the eye to pick out parts of it. Also, since it didn't go through a formal change process, I expect there was no testing to make sure that things that parse logs can handle the new format (and especially, handle it without additional configuration). For example, does fail2ban handle it okay?
FEDORA-2022-41186a924d has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-41186a924d
FEDORA-2022-41186a924d has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.