In these two cases we need to sync the journal _after_ the unit finishes as well, because we try to match messages from systemd itself, not (only) from the unit, and the messages about units are dispatched asynchronously. That is, in the first case (silent-success.service) we want to make sure that LogLevelMax= filters out messages _about_ units (from systemd) as well, including messages like "Deactivated..." and "Finished...", which are sent out only when/after the unit is stopped. In the second case we try to match messages with the "systemd" syslog tag, but these messages come from systemd (obviously) and are sent out asynchronously, which means they might not reach the journal before we call `journalctl --sync` from the test unit itself, like happened here: [ 1754.150391] TEST-04-JOURNAL.sh[13331]: + systemctl start verbose-success.service [ 1754.172256] bash[13692]: success [ 1754.221210] TEST-04-JOURNAL.sh[13694]: ++ journalctl -b -q -u verbose-success.service -t systemd [ 1754.221493] TEST-04-JOURNAL.sh[13331]: + [[ -n '' ]] [ 1754.175709] systemd[1]: Starting verbose-success.service - Verbose successful service... [ 1754.221697] TEST-04-JOURNAL.sh[122]: + echo 'Subtest /usr/lib/systemd/tests/testdata/units/TEST-04-JOURNAL.journal.sh failed' [ 1754.221697] TEST-04-JOURNAL.sh[122]: Subtest /usr/lib/systemd/tests/testdata/units/TEST-04-JOURNAL.journal.sh failed [ 1754.221697] TEST-04-JOURNAL.sh[122]: + return 1 [ 1754.205408] systemd[1]: verbose-success.service: Deactivated successfully. [ 1754.205687] systemd[1]: Finished verbose-success.service - Verbose successful service. By syncing the journal after the unit is stopped we have much bigger chance that the systemd messages already reached the journal - the race is technically still there, but the chance we'd hit it should be pretty negligible. Resolves: #39555
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS
