Non... celui-ci est un service "spécial" !
Si vous essayez de comprendre le fonctionnement de systemd avec celui-ci, vous allez avoir du mal !
En fait NetworkManager-wait-online.service est juste un service "creux" pour pouvoir mettre en dépendance les services qui ont besoin du réseau opérationnel pour tourner. Le service en lui-même ne fait rien, et ne laisse rien en résident, c'est juste un "top" pour mettre les liens After/Before.
Du reste l'optimisation de la 20.04 est impressionnante, maintenant la session n'attend plus précisément ce service là pour démarrer, ce qui fait que si vous avez paramétré votre PC en mise en session automatique, le démarrage est fulgurant...
On le voit en faisant un
$ systemd-analyze
Startup finished in 17.208s (firmware) + 3.383s (loader) + 2.215s (kernel) + 23.849s (userspace) = 46.656s
graphical.target reached after 23.825s in userspace
J'obtiens un temps d'environ 25 sec sur mon PC de bureau, dont plus la moitié sont consommées par le BIOS/EFI et les 2 secondes d'attente de GRUB.
Pour autant, après ces 25 secondes on a atteint "graphical.target" qui permet de commencer à afficher le bureau, mais le boot total prend un peu plus de 45 secondes (avec un SSD on ne rend compte de rien).
Donc quand on arrive à la session graphique affichée, s'il y a des choses en démarrage automatique qui ont besoin du réseau, en fait elle ne vont pas trouver celui-ci tout de suite, car le bureau graphique n'a pas attendu le service ci-dessus pour s'afficher.
Ainsi j'ai dû modifier mon utilitaire
1fichierfs (montage d'un compte 1fichier) que je lance automatiquement en "démarrage de session" afin de tourner sous le compte utilisateur (fuse recommande) pour qu'il attende sagement le réseau.
Si vous voulez comprendre systemd, prenez donc un service un peu plus "normal".
A ceux qui cassent du sucre sur systemd, c'est pourtant une amélioration géniale par rapport à init SystemV dont on commençait à avoir franchement besoin pour exploiter le parallélisme.
Le principe général utilisé est celui du "lazy loading" qui a été inventé historiquement par Linux/Unix pour les vieux qui s'en rappellent inetd. inetd cherchait en fait à résoudre un problème de mémoire et promettait sur une machine avec peu de RAM d'avoir "virtuellement" plein de services web lancés comme un serveur http, un serveur ftp, etc... En fait le service était vraiment lancé (d'où "lazy") lorsqu'une requête réseau sur ce service arrivait.
Le principe a été repris par Mac qui l'a généralisé à tout type de socket (socket linux) et pas seulement les sockets réseau, permettant un "lazy loading" généralisé de tous les services et des temps de chargement fulgurants sur un Mac.
Côté Linux, depuis l'idée inetd, le principe avait été un peu abandonné... les problèmes de mémoire sur un serveur sont d'un autre temps. Mais voyant le succès de la généralisation sur Mac, le système est maintenant aussi généralisé sur Linux.
Cela est cependant un travail colossal car il faut reprendre les services un par un pour vraiment définir les dépendances cruciales entre eux. Aussi certains sont encore "à améliorer". J'ai fait notamment
un rapport (launchpad) sur iscsci qui "casse" le principe de "lazy loading" de la mise en session rapide, malgré une tentative d'utiliser des sockets.
Donc au moins pour le "démarrage", un grand coup de refresh était nécessaire.
Après que Systemd s'occupe de plein de choses diverses et variées en plus d'un démarrage rapide est certes discutable !..
