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

[raid5atemyhomework]

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