On Wed, May 12, 2021 at 05:52:07PM +1000, Christopher James Halse Rogers wrote: > Hello everyone, > > 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? > > 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 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. >
I think there will be exceptions, and as long as they are documented, they should be fine. Take kdump-tools, for example. After a system crash, it will reboot into a mode that collects a memory dump and reboot. Some times, it is configured to send the dump through the network. If the network does not come up after some timeout, it should just reboot. And systemd machinery is leveraged to accomplish that. As long as that is what is happening and it's documented, I don't see a reason to not use After=network-online.target. Caveat: I am not claiming this is working exactly as described here, and there are always corner cases that we try to fix. Just pointing out an example that uses After=network-online.target and that maybe we should just use the implemented machinery instead of reimplementing it ourselves. Cascardo. > 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. > > Option (1) seems to be the technically superior option (and is recommended > by systemd upstream³), but appears to require more work. I have limited > insight into how much work that would be; someone from Foundations or Server > probably needs to weigh in on that. > > Option (2) seems to be formalisation of the status-quo, so would seem to be > less work. > > Let the discussion begin! > > ¹: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1918141 > ²: > https://github.com/ajtowns/debian-init-policy/blob/master/systemd-best-practices.pad > ³: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ > > > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
