Yu Watanabe
811af8d534
As you can see, something spurious happens in the logs below. ``` initrd-switch-root.target: Trying to enqueue job initrd-switch-root.target/start/isolate systemd-repart.service: Looking at job systemd-repart.service/stop conflicted_by=no systemd-repart.service: Looking at job systemd-repart.service/start conflicted_by=no systemd-repart.service: Fixing conflicting jobs systemd-repart.service/stop,systemd-repart.service/start by deleting job systemd-repart.service/stop initrd-switch-root.target: Fixing conflicting jobs initrd-switch-root.target/stop,initrd-switch-root.target/start by deleting job initrd-switch-root.target/stop systemd-repart.service: Deleting job systemd-repart.service/start as dependency of job initrd-switch-root.target/stop ``` The two conflicting jobs for systemd-repart.service are initially queued as the following: - initrd-switch-root.target has Wants=initrd-root-fs.target, and initrd-root-fs.target has Wants=systemd-repart.service (through symlink), hence starting initrd-switch-root.target tries to start systemd-repart.service, - systemd-repart.service has Conflicts=initrd-switch-root.target, hence starting initrd-switch-root.target tries to stop systemd-repart.service. As similar, interestingly(?) starting initrd-switch-root.target tries to stop initrd-switch-root.target. So, now there are at least two pairs of conflicting jobs: - systemd-repart.service: start vs stop, - initrd-switch-root.target: start vs stop. As these jobs are induced by starting initrd-switch-root.target, of course the most important one is the start job for initrd-switch-root.target. Previously, as you can see in the logs at the beginning, even if the start job for initrd-switch-root.target is important, we may first try to resolve the conflict in systemd-repart.service, and may drop the stop job for systemd-repart.service even if it is relevant to the start job of initrd-switch-root.target. This makes first we solve the pair of conflicting jobs for anchor task. So the stop job for initrd-switch-root.target is dropped first, and the induced start job for systemd-repart.service is automatically removed, thus it is not necessary to solve the conflict in systemd-repart.service anymore. This is especially important for services that are enabled both in initrd and after switching root. If a stop job for one of the service is unexpectedly dropped during switching root, then the service is not stopped before switching root, and will never start after that. Fixes #38765.
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