Previously, if the Synchronize() varlink call is issued we'd wait for journald to become idle before returning success. That is problematic however: on a busy system journald might never become idle. Hence, let's beef up the logic to ensure that we do not wait longer than necessary: i.e. we make sure we process any data enqueued before the sync request was submitted, but not more. Implementing this isn't trivial unfortunately. To deal with this reasonably, we need to determine somehow for incoming log messages whether they are from before or after the point in time where the sync requested was received. For AF_UNIX/SOCK_DGRAM we can use SO_TIMESTAMP to directly compare timestamps of incoming messages with the timestamp of the sync request (unfortunately only CLOCK_REALTIME). For AF_UNIX/SOCK_STREAM we can call SIOCINQ at the moment we initiate the sync, and then continue processing incoming traffic, counting down the bytes until the SIOCINQ returned bytes have been processed. All further data must have been enqueued later hence. With those two mechanisms in place we can relatively reliably synchronize the journal. This also adds a boolean argument "offline" to the Synchronize() call, which controls whether to offline the journal after processing the pending messages. it defaults to true, for compat with the status quo ante. But for most cases the offlining is probably not necessary, and is cheaper to do without, hence allow not to do it.
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
