On Mon, Dec 27, 2021 at 11:26 AM Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> wrote:
Hi!
debugging a problem I found out some surprising fact:
When filtering the journal with "journalctl -b _SYSTEMD_UNIT=logrotate.service", I see an error only once, like this:
-- Logs begin at Mon 2020-11-30 11:35:08 CET, end at Mon 2021-12-27 10:19:31 CET. --
Dec 18 00:00:20 h16 logrotate[41799]: Failed to kill unit \x7b__SERVICE__\x7d.service: Unit \x7b__SERVICE__\x7d.s...
Dec 18 00:00:20 h16 logrotate[41799]: error: error running shared postrotate script for '/var/log/iotwatch/MD10/...
However when inspecting the full journal I also see:
Dec 18 00:00:20 h16 systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Dec 18 00:00:20 h16 systemd[1]: Failed to start Rotate log files.
Dec 18 00:00:20 h16 systemd[1]: logrotate.service: Unit entered failed state.
Dec 18 00:00:20 h16 systemd[1]: logrotate.service: Failed with result 'exit-code'.
Actually I am surprised that those unit-related messages are not covered by the filter.
They're not generated *by* a process within logrotate.service, and journald does not allow a (fake) _SYSTEMD_UNIT to be set – not even if the sender is pid1. The same also applies to messages logged by systemd-coredump.
Is there a better way to get such related messages when filtering?
Use `journalctl -u logrotate`, which combines several filters to get all messages related to the specified unit.
The actual filtering used by -u (as seen with SYSTEMD_LOG_LEVEL=debug) is a union of four filters – the equivalent command would be:
journalctl _SYSTEMD_UNIT=logrotate.service \
+ MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 _UID=0 COREDUMP_UNIT=logrotate.service \
+ _PID=1 UNIT=logrotate.service \
+ _UID=0 OBJECT_SYSTEMD_UNIT=logrotate.service
The fourth is a generic filter (any process running as root can specify OBJECT_SYSTEMD_UNIT=) which I think came a bit later than the special-case pid1 and coredump ones.
Mantas Mikulėnas
