ae940730c6
compare_boot_ids() (from262299dccb) skips the tail entry realtime timestamp ordering when the compared locations are from two different machines (and hence have two different machine IDs) - in that case we fall through to a realtime comparison between the two locations. This works fine except for journals that were imported via systemd-journal-remote - the machine ID in the journal header is set to the receiving machine's ID instead of the original one; but the original machine ID is kept in the _MACHINE_ID= field. This, however, defeats the check in compare_boot_ids() so we treat the remote journals as local ones and try to compare the boots based on their tail entry realtime timestamps, which results in grouping the entries by their boot ID instead of interleaving them by their realtime timestamp. Given that we (transitively) call journal_file_read_tail_timestamp() from compare_boot_ids(), where we both (re)set the newest_machine_id field to the machine ID from the journal header and have the tail entry at hand, let's try to get the _MACHINE_ID= field from the tail entry and set newest_machine_id to that if it's present and valid. This way compare_boot_ids() will correctly determine that the entries are from two different machines and compare_locations() eventually falls through to the entry realtime check, so we end up with properly interleaved entries instead of entries grouped by boot ID. The performance impact should be pretty negligible in vast majority of cases, as we'd do this only when: - opening a new file - comparing entries across different boots - advancing to a next location The first case is a one-time thing only per journal. The second and third case might call this a bit more frequently, but we fall through to the _MACHINE_ID= parsing only if the journal file got a new entry since the last check. The most significant impact would be on journals that are being actively written into, but even then iterating through the handful of typical fields is negligible compared to what the rest of the function does. Also, since8f8ab4bf98the journal_file_read_tail_timestamp() calls are ratelimited when walking through the journal, lessening the impact even further. Resolves: #34169
System and Service Manager
Details
Most documentation is available on systemd's website.
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, and also repositories with packages built from the latest stable release