comprendre systemd

Ursul0720 · Le 09/08/2020, à 09:08

Bonjour,
malgré beaucoup de lecture je n'arrive pas à saisir les différents status d'un service.
Par exemple :
Quand je lance la commande :

xxx@xxx:~$ systemctl list-unit-files 'NetworkManager-w*service' | sort 
1 unit files listed.
NetworkManager-wait-online.service enabled enabled      
UNIT FILE                          STATE   VENDOR PRESET

L'état du service est activé.

Quand je lance la commande

xxx@xxx:~$ systemctl is-active NetworkManager-wait-online.service
inactive

L'état du service est inactive.

Je ne comprends pas.

Dernière modification par Ursul0720 (Le 09/08/2020, à 09:09)

Nuliel · Le 09/08/2020, à 09:21

Bonjour,
enabled ça veut dire que c'est lancé automatiquement au démarrage.
active, ça veut dire que le programme tourne actuellement

Dernière modification par Nuliel (Le 09/08/2020, à 09:21)

Ursul0720 · Le 09/08/2020, à 12:35

Merci, c'est plus clair.
Si je comprends bien pour le service "NetworkManager-wait-online.service", ça veut dire qu'il a été lancé au démarrage du système et qu'il s'est ensuite arrêté ?

Nuliel · Le 09/08/2020, à 14:41

Ca veut dire que systemd a tenté de le lancer au démarrage, et que cela a sûrement été un échec (je vois mal un service s'allumer puis s'éteindre)
Tu peux donner

journalctl -u NetworkManager-wait-online.service

Ursul0720 · Le 09/08/2020, à 22:18

et voilà :

xxx@xxx:~$ journalctl -u NetworkManager-wait-online.service
-- Logs begin at Sat 2020-07-25 08:27:35 CEST, end at Sun 2020-08-09 22:17:46 CEST. --
-- No entries --

Nuliel · Le 10/08/2020, à 10:08

J'espérais des erreurs, mais au final on voit surtout que ça démarre pas non plus.
Tu peux faire

sudo systemctl start NetworkManager-wait-online.service

donner

journalctl -p err
systemctl status NetworkManager-wait-online.service

Zakhar · Le 10/08/2020, à 16:25

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 !..

Dernière modification par Zakhar (Le 10/08/2020, à 21:11)

Ursul0720 · Le 16/08/2020, à 16:10

Bonjour,

Merci pour vos explications, même si je n'ai pas tout saisi. Du coup est-ce que le "lazy loading" est un équivalent du "démarrage manuel" d'un service dans windows ?

Du coup si "NetworkManager-wait-online.service" n'est pas un bon exemple j'en ai trouvé deux autres qui sont dans la même situation (enabled / inactive) :
casper.service
dmesg.service

diesel · Le 16/08/2020, à 16:20

Je profite de ce fil pour squatter un peu même si je pense que je ne suis pas le seul à me poser cette question (et que ce n'est pas totalement hors sujet).

systemd fonctionne à partir d'évènements. Par exemple, si je prends le service avahi, celui-ci réclame pour son démarrage l'évènement "avahi-daemon.socket" (ligne : Requires=avahi-daemon.socket du fichier avahi-daemon.service).

Quelqu'un sait-il où on peut trouver la liste exhaustive de tous les évènements gérés par le système ainsi que leur description ?

Amicalement.

Jean-Marie

Dernière modification par diesel (Le 16/08/2020, à 16:22)

Ursul0720 · Le 22/08/2020, à 12:36

Plus personne ?

Diesel, peux-être une piste ici : https://blog.seboss666.info/2015/03/que … e-systemd/

bruno · Le 22/08/2020, à 12:56

diesel a écrit :

systemd fonctionne à partir d'évènements. Par exemple, si je prends le service avahi, celui-ci réclame pour son démarrage l'évènement "avahi-daemon.socket" (ligne : Requires=avahi-daemon.socket du fichier avahi-daemon.service).

systemd ne fonctionne pas à partir d'événements.
systemd est un gestionnaire de services qui fonctionne avec un système de dépendances entre « unités » (service, socket, timer, etc. 11 types diffrents en tout).

D'ailleurs dans ton exemple tu vois bien qu'un socket n'est pas un événement, c'est un canal de communication inter processus, le service avahi qui est un démon ne peut démarrer que si le socket avahi est établi.

cf. https://www.freedesktop.org/software/sy … stemd.html

La liste des unités systemd présentes sur le système s'obtient avec :

systemctl list-units

cf. man systemctl

On peut aussi regarder le contenu de /lib/systemd/system et /etc/systemd/system

diesel · Le 22/08/2020, à 13:20

Bonjour Bruno.

Tout d'abord, merci beaucoup pour ta réponse.

Effectivement, le terme d'évènement n'est probablement pas approprié. Cependant, si un socket n'est bien évidement pas un évènement, l'établissement de celui-ci (ou sa fermeture) s'en rapproche quand même.

Amicalement.

Jean-Marie

diesel · Le 22/08/2020, à 13:27

Ursul0720 a écrit :

Plus personne ?
Diesel, peux-être une piste ici : https://blog.seboss666.info/2015/03/que … e-systemd/

Merci beaucoup.

Amicalement.

Jean-Marie

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 09/08/2020, à 09:08

comprendre systemd

#2 Le 09/08/2020, à 09:21

Re : comprendre systemd

#3 Le 09/08/2020, à 12:35

Re : comprendre systemd

#4 Le 09/08/2020, à 14:41

Re : comprendre systemd

#5 Le 09/08/2020, à 22:18

Re : comprendre systemd

#6 Le 10/08/2020, à 10:08

Re : comprendre systemd

#7 Le 10/08/2020, à 16:25

Re : comprendre systemd

#8 Le 16/08/2020, à 16:10

Re : comprendre systemd

#9 Le 16/08/2020, à 16:20

Re : comprendre systemd

#10 Le 22/08/2020, à 12:36

Re : comprendre systemd

#11 Le 22/08/2020, à 12:56

Re : comprendre systemd

#12 Le 22/08/2020, à 13:20

Re : comprendre systemd

#13 Le 22/08/2020, à 13:27

Re : comprendre systemd

Pied de page des forums