bug#47253: network-manager shepherd services does not wait to be online

[raid5atemyhomework via Bug reports for GNU Guix <bug-guix@gnu.org>]

Hello Mark,

> > Of course, the big problem is that Shepherd is single-threadded and
> > `nm-online` will block all other bootup.
>
> That's not good. For the sake of users who are not always connected to
> the internet, I'd strongly prefer for the Guix boot process of a desktop
> system to not be blocked for 30 seconds when there's no active
> internet connection.
>
> How about leaving "networking" as it is now, and instead adding a new
> service called "network-online" or similar, that requires "networking"
> and then waits until a network connection is established?
>
> What do you think?


Ideally the `init` system should be multithreaded, such that anything that isn't dependent on `networking` does not get delayed but gets started as soon as its dependencies complete.

In particular, `transmission-daemon-service-type` creates a Shepherd service that is dependent on `networking`, but is in fact the second daemon I mentioned, which fails to properly bind to the command 9091 port, requiring the daemon to be restarted each time.  So if we use a separate `network-online` shepherd provision, `transmission-daemon-service-type` also needs to be modified (on my system I have a separate provision similar to your `network-online` idea and I wrote my own shepherd service for `transmission-daemon` just to add this requirement).

With a separate `network-online` shepherd provision we would also need to audit all the other network-requiring daemons to see if similar problems exist.

As well, `networking` is provided by multiple possible services, so if we add a separate `network-online` we also need to modify the other options.

* `network-manager-service-type`.
* `dhcp-client-service-type`.
* `wicd-service-type`.
* `connman-service-type`.

For that matter, we probably need to review the above other options, as they might just start up the networking service without actually ensuring that the networking service has actually completed.  I use `network-manager-service-type` as part of `%desktop-services` but if this issue isn't properly handled by Guix for NetworkManager then it probably isn't properly handled for the above other options --- in all likelihood the network interfaces are not available just after the networking shepherd services are started.

In addition --- do we always have a `network-online` shepherd service, or not?

* Each of the `network-manager-service-type`, `dhcp-client-service-type`, `wicd-service-type`, `connman-service-type` instantiate both a `networking` and `network-online` shepherd provision.
  * Then other network-requiring services can always assume that `network-online` exists.
  * However, not-always-online users would always find that `shepherd` completion is delayed.
    * This manifests as `herd` commands not responding until the wait-to-be-online timeout ends.
* We have separate `network-manager-online-service-type`, `dhcp-client-online-service-type`, `wicd-online-service-type`, and `connman-online-service-type` that provides the `network-online` shepherd provision to the corresponding `networking` backend.
  * Thus, not-always-online users would omit the `*-online-*` service type in order not to suffer the wait.
  * However, the user has to know to add the *corresponding* service type as well if they have to use a daemon like `transmission-daemon`.
  * Do we add `network-manager-online-service-type` to `%desktop-services`?
    * I think we should, as most `%desktop-services`-using users will be mostly online anyway, and they are the ones most likely to want to start other network-using services as well.
* We somehow implement polymorphic service types so that services like `transmission-daemon` have a `(service-extension i-need-network-online-service-type (const #f))`, which only instantiates `network-online` provision, appropriately for the network backend, if at least one service requires it.
  * Probably a lot more code and design and nerd wars about the best possible design and delays and ...

What do *you* think?


Note as well that in the SystemD case, typically, `NetworkManager-wait-online.service` is always enabled, and when I boot up my system on SystemD-based OSs even without any network available I don't experience any network-going-up delays during boot (at least in the last few years, I do remember circa oughts Ubuntu having that problem).

In addition, `nm-online -s` has this:

>       -s | --wait-for-startup
>           Wait for NetworkManager startup to complete, rather than waiting for network connectivity specifically. Startup is considered complete once NetworkManager has activated (or
>           attempted to activate) every auto-activate connection which is available given the current network state. (This is generally only useful at boot time; after startup has
>           completed, nm-online -s will just return immediately, regardless of the current network state.)

My interpretation of the above is that `-s` means that NetworkManager has *tried* to activate, not necessarily that there is an actual network connection, but I am not an expert on NetworkManager.

Thanks
raid5atemyhomework