On Thu, May 13, 2021 at 4:12 PM Steve Langasek <steve.langa...@ubuntu.com> wrote: > > Hi there, > > On Wed, May 12, 2021 at 05:52:07PM +1000, Christopher James Halse Rogers > wrote: > > There's an nfs-utils SRU¹ hanging around waiting for a policy decision on > > use of the After=network-online.target systemd unit dependency. I'm not an > > expert here, but it looks like part of my SRU rotation today is starting the > > discussion on this so we can resolve it one way or another! > > > I am not an expert in this area, but as I understand it, the tradeoff here > > is: > > 1. Without a dependency on After=network-online.target there is no guarantee > > that the network interface(s) will be usable at the time the nfs-utils unit > > triggers, and nfs-utils will fail if the relevant ntwork interface is not > > usable, or > > 2. With a dependency on After=network-online.target nfs-utils will reliably > > start, but if there are any interfaces which are configured but do not come > > up this will result in the boot hanging until the timeout is hit. > > > In mitigation of (2), there are apparently a number of default packages > > which already have a dependency on After=network-online.target, so boot > > hanging if interfaces are down is the status quo? > > From one of the comments in the bug report, I gathered that systemd upstream > (who, specifically?) was taking a position that distributions should not use > After=network-online.target. I think this is entirely unhelpful; the target > exists for this purpose, it is not required for systemd internally to get > the system up but exists only for other services to depend on. > > There are risks of services not starting on boot because the network-online > target is not reached. However, that is not the same thing as a "hung > boot", because other services will still start on their own, and things like > gdm and tty don't depend on network-online.target, *unless* you're in a > situation where you've introduced a dependency between the filesystem and > network-online. This is possible when we're talking about nfs, because the > same system might both export nfs filesystems and mount them from localhost. > But I'm not sure it should block this specific change. > > > The obvious thing to do here would be to follow Debian, but as far as I can > > tell there is not currently a Debian policy about this - the best I can find > > is an ancient draft of a best-practises-guide² suggesting that pacakages > > SHOULD handle networking dynamically, but if they do not MUST have a > > dependency on After=network-online.target > > > As far I understand it, handling networking dynamically requires upstream > > code changes (although maybe fairly simple code changes?). > > It does require upstream code changes; not always simple. And it's not > always *correct* to make upstream code changes instead of simply starting > the service when the system is "online"; you can find a number of examples > in Ubuntu of services that it only makes sense to start once your network is > "up" - e.g. apt-daily.service, update-notifier, whoopsie, ... > > > There are issues with the network-online target, to be sure. There is not a > clear definition of the target, and there have definitely been > implementation bugs in what does/does not block the target. I've had > discussions with the Foundations Team in the past about this but it has yet > to result in a specification. > > My working definition of what network-online.target SHOULD mean is: > > - at least one interface is up, with routes > - all interfaces which are 'optional: no' (netplan sense) are up > - including completion of ipv6 RA and ipv4 link-local if enabled on the > interface > - there is a default route for at least one configured address family > - attempts to discover default routes for other configured address families > have completed (success or fail) > - DNS is configured > > Thinks that must not block the network-online target: > - interfaces that are marked 'optional: yes' > - address sources that are listed in 'optional-addresses' for an interface > - default route for an address family for which no interfaces have > addresses > > At least historically, neither networkd nor NetworkManager has fulfilled > this definition. It would be nice to get there, but the first step is > having some agreed definition such as the above so that we can treat > deviations as bugs. >
If netplan.io can implement that would be nice. I.e. either synthetically (i.e. by generating a service unit on the fly that calls systemd-networkd-wait-online with extra arguments specifying all the non-optional interfaces) , or by creating a new binary which is "netplan-wait-online" which will be wanted by network-online.target and perform all of the above. > > It seems unlikely that, whatever we decide, we'll immediately do a full > > sweep of the archive and fix everything, so it looks like our choice is > > between: > > > 1. The long-term goal is to have no After=network-online.target dependencies > > in default boot (stretch goal: in main). Whenever we run into a > > package-fails-if-network-is-not-yet-up bug, we patch the code and submit > > upstream. Over time we audit existing users of After=network-online.target > > and patch them for dynamic networking, as time permits. > > > 2. We don't expect to be able to reach no After=network-online.target > > dependencies in the default boot, so it's not a priority to avoid them. > > Whenever we run into a package-fails-if-network-is-not-yet-up bug, we add an > > After=network-online.target dependency. > > 3. We expect to reach network-online.target in the common case, but accept > that there are systems for which it will ordinarily not be reached on boot > (i.e. offline systems). Services which depend on network-online.target > should be those which it is reasonable to not start if the system is not > connected to the Internet. This includes systems that are connected to a > local network, but have no default route. > So from my point of view a short term fix of like having After=network-online.target or even [Unit] After=systemd-resolved.service [Service] ExecStartPre=-/lib/systemd/systemd-networkd-wait-online --any --timeout 30 Is fine to be SRUed. However, I still have the same question - what if network connectivity drops & gets re-established? Should we bounce the network-online.target (aka restart it)? We can declare for units to be restarted, when network-online.target is restarted, if they otherwise themselves are incapable to dynamically detect networking loss & networking resumption. > > If we use this as the standard, it's easy to see that *in principle* > nfs-utils shouldn't depend on there being a route to the global Internet. > It does, however, at least give us a framework for understanding the > behavior, and for users to modify the behavior if they have different > requirements. > > > None of this makes it any safer for an SRU, since at the end of the day if > users have such a config that is impacted if you set > After=network-online.target for nfs-utils, it would still be a regression. > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
