Zbigniew Jędrzejewski-Szmek
9db307820e
In the initial design, foobar-wait-online.service would have Requisite=foobar.service, so that foobar-wait-online.service could be enabled unconditionally, irrespective of whether foobar.service itself is enabled. Unfortunately this doesn't work too well: 1. the message about foobar-wait-online.service being skipped because of a "missing dependency" *looks* like an is problem. This is mostly cosmetic, but it also quite confusing. We generally don't want any messages of this type during default boot. 2. it is impossible to start and wait for the network in an implementation-agnostic way: systemctl start network-online.target, or Wants/After=network-online.target in a unit don't work because pulling in network-online.target pulls in foobar-wait-online.service, but it in turn does not pull in foobar.service. During startup, foobar.service is pulled in by multi-user.target, but not in a smaller transaction which does not include multi-user.target. This change means that *-wait-online.service should be installed through presets, so that it can be enabled/disabled at will by the administrator. Our own systemd-networkd-wait-online.service does this already, and similar change has been requested for NetworkManager-wait-online.service (https://bugzilla.redhat.com/show_bug.cgi?id=1455704). This change should by mostly backwards-compatible, unless somebody has some wait-online.service enabled, without having the corresponding network implementation enabled, and they are relying on it not being started. I think that's relatively unlikely because of issue 1. above, and I'm not aware of this being the default in any distro. And being able to start the network in an implementation-agnostic way is pretty important, see https://bugzilla.redhat.com/show_bug.cgi?id=1452866.
systemd - System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements are provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the HACKING file for information 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.