Luca Boccassi
059b3b466d
Loading images is, generally speaking, the slowest part of sd-executor when spawning a service. This is due to multiple factors. dm-verity is obviously a big part of the cost, but dissecting in general via libblkid also can take a lot of time, due to probing the images and their filesystems. A performance test doing service restarts in a row shows these results, ran on a production system (low power and slow ARM64 SOC) with a real production service, show the following service interruption intervals: ``` Count | P50 (ms) | P90 (ms) | P95 (ms) | P99 (ms) | P99.9 (ms) 507 | 1,532 | 1,726 | 2,548 | 4,112 | 4,592 ``` One iteration is 507 restarts in this case, but this has ran hundreds of times and the results are always in line within margin of error. This also holds true for metrics from live systems, same numbers. Between 1.0s and 1.2s can be attributed by profiling to the time needed for the service code itself to start up and sd_notify, the rest is spent inside systemd's code. This means there is currently a tradeoff for services - either use secure images, or make restarting fast. Downtime of services is a very important metric, as for many cases this directly translates to outages, total or partial (blackouot or greyout). In order to facilitate using secure images without downsides, skip the slow dissect steps (probing, loop devices, etc) when the configured image is a single filesystem dm-verity image with a policy that pins it to a single filesystem, and an already existing and open dm-verity device can be found and reused. This allows orchestrators to pre-open images on download, before restarting services, to minimize downtimes.
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