ce92dc27a1
This is a follow-up for 1d8d483f59ffa62974772fb58a8ef4abe88550ec and makes the strict ordering by realtime clock within each journal file optional, not mandatory. It then enables it for all journal files written by journald, but leaves it off on others (for example those written by journald-remote). This relaxes the logic behind writing journal files to the status quo ante for all cases where the journal files are not generated, but are merged/processed/propagated. Typically when processing journal records from many files ordering by realtime clock and monotonic clock are contradictory, and cannot be universally guaranteed as the records are interleaved. By enforcing strict rules we would thus end up generating myriads of separate journal files, each with just a few records in them. Hence, let's losen restrictions again, but continue to enforce them in journald, i.e. when we original create the journal files locally. Note that generally there's nothing really wring with having journal files with non-monotonically ordered entries by realtime clock. Looking for records will not be deterministic anymore, but that's inherent to a realtime clock that jumps up and down. So you won't get the "only" answer, but still *a* answer that is correct if you seek for a realtime clock. This also adds similar logic on the monotonic clock, which is also only enabled when generating journal files locally. This should be harder to trigger (as journald will generate the messages, and should run with a stable boot id and monotonic clock), but let's better be safe than sorry, and refuse on the lower layer what makes no sense, even if it's unlikely the higher layer will ever generate records that aren't ordered by their monotonic clock.
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 or join our IRC channel.
Stable branches with backported patches are available in the stable repo.