Démarrage de Linux avec Systemd

Vous avez vu, sur la page précédente, que la noyau linux a pris la relève du BIOS ou de UEFI, grâce au chargeur de démarrage (GRUB2 par exemple).
Le noyau initialise différents composants matériels (processeur, périphériques, carte graphique ...)
Le noyau lance /usr/sbin/init qui est un lien vers /usr/lib/systemd/systemd
Pour des raisons de compatibilité, il existe également un fichier /usr/bin/systemd et qui pointe également vers /usr/lib/systemd/systemd.

Le noyau exécute donc le processus numéro 1, /usr/lib/systemd/systemd. Son fichier de configuration est : /etc/systemd/system.conf. Ce dernier permet de modifier le système de journalisation (logs) ainsi que quelques autres paramètres, surtout intéressants pour le débogage.

Le mode de démarrage de l'ordinateur (anciennement appelé le runlevel) est donné par le fichier /etc/systemd/system/default.target.

C'est un lien symbolique vers l'un des fichiers correspondant aux anciens runlevel, situés dans le répertoire /usr/lib/systemd/system/ :

• runlevel0.target pointe vers poweroff.target
• runlevel1.target pointe vers rescue.target
• runlevel2.target pointe vers multi-user.target
• runlevel3.target pointe vers multi-user.target
• runlevel4.target pointe vers multi-user.target
• runlevel5.target pointe vers graphical.target
• runlevel6.target pointe vers reboot.target
• emergency.target

Avant de poursuivre dans le processus de démarrage, il faut comprendre le système des unités de systemd.

Systemd fait appel à la notion d'Unités. Une unité représente un fichier de configuration. Entre autres, une unité peut être :

• un fichier .service : lancement et administration de processus (services) et précision des conditions,
• un fichier .socket : lancement d'une socket de type Unix ou réseau, associée à un service (les clients pourront se connecter à ces sockets)
• un fichier .target : permet de regrouper différents services et sockets (par exemple faire démarrer plusieurs services qui seront énumérés dans un répertoire .target.wants,)
• un répertoire .target.wants : ce n'est pas une unité, mais il complète une unité, en précisant tous les services à démarrer pour une unité .target donnée. Le répertoire .target.wants contient des liens symboliques pointant chacun vers des fichiers .service, tels que décrits ci-dessus.
• un fichier .mount : gestion des montages selon le fichier /etc/fstab
• un fichier .automount : auto-montage par autofs
• un fichire .path
• un fichier .timer

Ces fichiers et répertoires se trouvent dans le répertoire /etc/systemd/system, pour ceux qui sont paramétrables par l'administrateur système, et dans le répertoire /usr/lib/systemd/system pour les autres.

Les unités .service permettent notamment de lancer une commande par une ligne ExecStart=

La syntaxe est inspirée des fichiers .desktop, avec des groupes fonctionnels [Unit], [Service] et [Install]

1. [Unit] contient la description du service et la gestion des interactions avec les autres services (requires, conflicts, after ...)
2. [Service] décrit les commandes lancées par le service et, éventuellement, celles pour le relancer, le tuer ...
3. [Install] décrit comment il sera installé (demandé par, alias ...)

Il vient en complément d'un fichier .service et comprend les groupes fonctionnels [Unit], [Socket] et [Install]

1. [Unit] contient la description du socket
2. [Socket] décrit la ou les socket(s) qui peuvent être des sockets unix ou réseau (TCP, UDP)
3. [Install] décrit comment il sera installé (demandé par, alias ...)

Une cible (target) est un groupe fonctionnel d'unités. Elle est définie par un fichier .target.

Les fichiers des unités .target ne renseignent pas directement sur les commandes à exécuter. C'est un répertoire .target.wants qui donnent des liens vers des fichiers .service ou vers d'autres fichiers .target.

Dans la pratique, il peut y avoir deux répertoires .target.wants, l'un dans /etc/systemd/system, l'autre dans /usr/lib/systemd/system.

Compte tenu du grand nombre d'unités, il serait fastidieux d'analyser tous les fichiers de définition. Voici quelques exemples.

La première unité que nous rencontrons est default.target

Afin de simplifier les écritures, les conventions suivantes s'appliquent :

• → représente un lien vers un autre fichier ou répertoire
• (etc) représente /etc/systemd/system
• (usr) représente /usr/lib/systemd/system
• @ est placé devant le nom d'un lien

L'unité default.target

Elle est définie par un fichier /etc/systemd/system/default.target

Le fichier /etc/systemd/system/default.target

C'est un lien qui renvoie à → (usr)/runlevelx.target
x=3 si vous démarrez en mode texte, sinon x=5, ce qui est généralement le cas.

En résumé

L'unité default.target renvoie vers l'unité qui doit effectivement être démarrée, en l’occurrence runlevel5.target en mode graphique.

L'unité runlevel3.target (systemd-units-230-12.mga6)

Cette unité est définie par un fichier (usr)/runlevel3.target et un répertoire (usr)/runlevel3.target.wants.

Le fichier (usr)/runlevel3.target

C'est un lien qui renvoie à → (usr)/multi-user.target

Le répertoire (usr)/runlevel3.target.wants

Il est actuellement vide

En résumé

Dans le mode console (runlevel3), runlevel3.target renvoie vers l'unité multi-user.target

L'unité runlevel5.target (systemd-units-230-12.mga65)

Cette unité est définie par un fichier (usr)/runlevel5.target et un répertoire (usr)/runlevel5.target.wants.

Le fichier (usr)/runlevel5.target

C'est un lien qui renvoie à → (usr)/graphical.target

Le répertoire (usr)/runlevel5.target.wants

Il est actuellement vide

En résumé

Dans le mode graphique (runlevel5), runlevel5.target renvoie vers l'unité graphical.target

L'unité multi-user.target (systemd-units-230-12.mga6)

Cette unité est définie par un fichier (usr)/multi-user.target, un répertoire (etc)/multi-user.target.wants et un autre répertoire (usr)/multi-user.target.wants.

Le fichier (usr)/multi-user.target

L'unité multi-user.target

• est incompatible avec rescue.service, rescue.target
• nécessite basic.target
• soit démarrée après basic.target, rescue.service, rescue.target
• peut être démarrée manuellement

Le répertoire (etc)/multi-user.target.wants

Ce répertoire contient plusieurs liens symboliques : acpid.service, cpupower.service, crond.service, shorewall.service, shorewall6.service, pointant tous vers des fichiers du même nom dans le répertoire → (usr)/. D'autre liens peuvent encore exister en fonction des applications installées.

Le répertoire (usr)/multi-user.target.wants

Ce répertoire contient également plusieurs liens symboliques : dbus.service, getty.target, plymouth-quit-wait.service, plymouth-quit.service, rpcbind.target, systemd-ask-password-wall.path, systemd-logind.service, systemd-update-utmp-runlevel.service, systemd-user-sessions.service, pointant tous vers des fichiers du même nom dans le répertoire → (usr)/

En résumé

Le fichier multi-user.target nous dit que l'unité basic.target est nécessaire et qu'elle doit déjà être en cours d'exécution. Les répertoires (etc)/multi-user.target.wants et (usr)/multi-user.target.wants nous disent que plusieurs autres unités sont nécessaires (souvent des services). Cela dépend des applications et surtout des serveurs qui sont installés.

Afin de suivre le déroulement du processus de démarrage, quelques commandes sont utiles.

Plusieurs services sont lancés avant qu'un utilisateur ne puisse se connecter.

Le siège

Il s'agit de tout le matériel assigné à une place de travail donnée. Il y a au moins un moniteur, un clavier et habituellement une souris. Il peut également inclure une caméra vidéo, une carte son ...
Ils sont identifiés par leur nom qui commence par seat suivi par au moins un caractère (Ex. seat0).

Dans un système classique, il n'y a qu'un seul siège. Mais un ordinateur peut en avoir plusieurs, permettant à plusieurs personnes de l'utiliser simultanément. Les sièges sont indépendants les uns des autres (affichage différent, éventuellement matériel différent ...). Tout matériel peut être attaché à un siège, mais alors à un seul siège à la fois L'interface réseau restera normalement non attachée afin de servir à tous les utilisateurs..

La session

Elle est déterminée par le moment où un utilisateur se connecte jusqu'au moment où il se déconnecte. Plusieurs sessions peuvent être attachées à un même siège, mais une seule peut être active.
Elle est constituée d'un groupe de process tournant sous le contrôle d'un seul utilisateur. La session peut démarrer et arrêter des process, mais ne peut pas s'échapper de la session.

Uniquement les démons du système (qui ne sont donc pas attachés à une session) peuvent engendrer de nouvelles sessions.

Habituellement une session comprend plusieurs démons procurant des services pour la session (le serveur-X procure des accès graphiques vers d'autres process de session, pulseaudio procure les accès audio ...)
Quand une session est engendrée, le premier processus (processus central) contrôle la session. Il l'initialise, engendre d'autres processus.

Pendant le démarrage, systemd démarre plusieurs démons pour gérer le système. Tous ces démons sont globaux et ne sont pas attachés à un siège ou à une session.

Après son démarrage, systemd met en place les cgroups (control groups) et il les monte dans /sys/fs/cgroup/.
Systemd recherche ensuite les unités à prendre en compte, dans /etc/systemd/system et dans /usr/lib/systemd/system. Une fois que la liste des unités est connue, systemd active l'unité default.target qui renvoie vers multi-user.target (en mode texte) ou graphical.target (en mode graphique).

À partir de là, le contenu change en fonction du mode de démarrage, mais la démarche reste la même.

1. examen du lien vers l'unité effective de démarrage,
2. recherche et règlement des conflits possibles avec cette première unité,
3. installation, ensuite, des différentes unités induites par la première unité,
4. installation de l'unité qui permet à l'utilisateur de se connecter,
5. exécution des actions définies par les unités.

La tranche système : system.slice

Parmi ces démons se trouve systemd-login, responsable de la gestion des sessions et des sièges.

Avec systemd-cgls nous trouvons d'abord la tranche système system.slice qui regroupe les services relatifs au système, donc globaux (pour mémoire, il s'agit ici d'une installation minimale, sans le serveur-X) :

Control group /:

-.slice

┣ init.scope

┃  ┗ 1 /sbin/init

┗ system.slice

    ┣ irqbalance.service

    ┃  ┗ 660 /usr/sbin/irqbalance --foreground

    ┣ alsa-state.service

    ┃  ┗ 644 /usr/sbin/alsactl -s -n 19 -c rdaemon

    ┣ mandi.service

    ┃  ┗ 1811 /usr/sbin/mandi -d

    ┣ dbus.service

    ┃  ┗ 664 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfi...

    ┣ powernowd.service

    ┃  ┗ 708 /usr/sbin/powernowd

    ┣ prefdm.service

    ┃  ┣ 1238 /usr/bin/xdm -nodaemon

    ┃  ┗ 1277 /usr/libexec/Xorg -deferglyphs 16 -auth /var/lib/xdm/authdir/authf...

    ┣ network.service

    ┃  ┣ 954 /sbin/ifplugd -I -b -i enp3s0

    ┃  ┗ 1149 dhclient -1 -q -lf /var/lib/dhclient/dhclient--enp3s0.lease -pf /v...

    ┣ gpm.service

    ┃  ┗ 652 /usr/sbin/gpm -m /dev/input/mice -t exps2

    ┣ systemd-logind.service

    ┃  ┗ 636 /usr/lib/systemd/systemd-logind

    ┣ systemd-resolved.service

    ┃  ┗ 1218 /usr/lib/systemd/systemd-resolved

    ┣ crond.service

    ┃  ┗ 1230 /usr/sbin/crond -n

    ┣ polkit.service

    ┃  ┗ 1923 /usr/lib/polkit-1/polkitd --no-debug

    ┣ systemd-udevd.service

    ┃  ┗ 496 /usr/lib/systemd/systemd-udevd

    ┣ acpid.service

    ┃  ┗ 668 /usr/sbin/acpid

    ┣ systemd-journald.service

    ┃  ┗ 450 /usr/lib/systemd/systemd-journald

    ┣ systemd-networkd.service

    ┃  ┗ 699 /usr/lib/systemd/systemd-networkd

    ┗ chronyd.service

        ┗ 651 /usr/sbin/chronyd

Partie responsable du démarrage graphique

Pour le démarrage en mode graphique, il y a des groupes supplémentaires :

    ┣ prefdm.service

    ┃  ┣ 1238 /usr/bin/xdm -nodaemon

    ┃  ┗ 1277 /usr/libexec/Xorg -deferglyphs 16 -auth /var/lib/xdm/authdir/authf...

Prefdm.service recherche quel est le gestionnaire de connexion qu'il faut utiliser. Ici c'est xdm. Il lance également le serveur X

Dans les groupes de contrôle il y a l'unité systemd-logind.service qui est un service permettant de gérer les sessions utilisateur.

L'extrait de systemd-cgls montre le groupe de process (la tranche) user.slice, le sous-groupe user-1000.slice avec l'unité user@1000.service. Elle lance le service gpg-agent avec le process /usr/bin/gpg-agent --daemo et elle lance également le scope init avec les process //usr/lib/systemd/systemd --user et (sd-pam):

Control group /:

-.slice

┣ user.slice

┃  ┗ user-1000.slice

┃     ┣ user@1000.service

┃     ┃ ┣ gpg-agent.service

┃     ┃ ┃  ┗ 1829 /usr/bin/gpg-agent --daemon

┃     ┃ ┗ init.scope

┃     ┃     ┗ 1822 /usr/lib/systemd/systemd --user

┃     ┃     ┗ 1825 (sd-pam)

Comme vu ci-dessus, nous trouvons les tranches utilisateur user.slice et user-1000.slice.
Cette dernière contient :

• user@1000.service qui lance le service gpg-agent, une instance de systemd ainsi que pam-systemd (vus ci-dessus),
• session-c1.scope qui regroupe tous les processus lancés par l'utilisateur.

pam-systemd enregistre les sessions utilisateur à l'aide du gestionnaire systemd-login.service. Un nouveau scope est créé pour la session et ce scope est placé dans le sous-groupe de l'utilisateur. Extrait de systemd-cgls :

┗user.slice

   ┗user-1000.slice

      ┗session-c1.scope

Le groupe scope contient tous les process lancés par l'utilisateur.

L'utilisateur démarre en mode texte et lance la commande systemd-cgls. Un extrait donne :

┗user.slice

   ┗user-1000.slice

     ┗session-c1.scope

        ┣ 1887 login -- paiiou

        ┣ 1911 -bash

        ┗ 1952 systemd-cgls

Si l'utilisateur a décidé de démarrer en mode graphique avec xdm et IceWM, dmesg nous informe que :

• l'unité default.target renvoie à l'unité graphical.target,
• il y a des conflits à résoudre : supprimer les jobs plymouth-quit.service/start, prefdm.service/stop et getty@tty1.service/start,
• graphical.target nécessite multi-user.target.

Avec systemd-cgls, nous avons vu ci-dessus, dans la partie Avant une session utilisateur que nous trouvons d'abord la tranche système system.slice qui, comme pour le démarrage en mode texte, regroupe les mêmes services relatifs au système avec, en plus, une unité prefdm.service.

Il faut donc s'attendre à voir beaucoup de points communs avec le démarrage en mode texte : multi-user.target et toutes ses dépendances.
Avec, bien sûr, des éléments supplémentaires, dont le job prefdm.service/start qui recherche un écran graphique de connexion.

Choix du gestionnaire de connexion

prefdm.service lance la commande /etc/X11/prefdm -nodaemon

Déroulement de prefdm :

1. récupère la langue système avec /etc/profile.d/10lang.sh afin d'avoir les traductions -> $LANG = fr.FR.UTF8
2. vérifie si autologin est installé (/usr/sbin/autologin) et est configuré (/etc/sysconfig/autologin)
   Si oui, exécute le fichier /etc/sysconfig/autologin qui doit définir un utilisateur et doit valider par AUTOLOGIN=yes
   Mais autologin semble ne pas fonctionner actuellement.
3. si un fichier /etc/sysconfig/desktop existe, vérifie si le gestionnaire de connexion est spécifié dans ce fichier et affecte sa valeur à dm
   $DISPLAYMANAGER peut prendre les valeurs : GNOME, gnome, Gnome, GDM, gdm, SDDM, sddm, PLASMA5, plasma5, WDM, wdm, XDM, xdm, SLiM, slim, LXDM, lxdm, selon la configuration faite.
   /etc/X11/prefdm en déduit une variable $dm dont la valeur peut être : GNOME, SDDM, WDM, XDM, SLiM, LXDM
4. exécute le fichier /etc/sysconfig/firstboot s'il existe encore (Mageia ne l'utilise plus)
5. exécute le fichier /etc/sysconfig/finish-install s'il existe (le paquetage finish-install permet d'affiner les installations oem et n'est habituellement pas installé)
6. exécute le fichier /etc/X11/lookupdm "$dm". Son rôle est de vérifier si le gestionnaire que vous avez choisi est effectivement présent, et de choisir un gestionnaire par défaut, dans le cas où votre choix pose un problème :
   • si $dm est déjà définie, cherche dans /usr/share/dm.d un fichier *.conf contenant NAME=$dm et cherche l'exécutable associé (EXEC=)
   • sinon, cherche dans /usr/share/dm.d le premier fichier contenant le nom d'un exécutable (EXEC=)
   • renvoie le nom de cette commande
7. exécute la commande et quitte ce script
8. si la commande échoue, essaie gdm ou sddm

Comme en mode texte, nous trouvons ensuite les tranches utilisateur user.slice et user-1000.slice.
Cette dernière contient :

• user@1000.service qui lance une instance de gpg-agent, de systemd ainsi que pam,
• session-c1.scope qui regroupe tous les processus lancés par l'utilisateur.

Voici le contenu de session-c1.scope :

Control group /:

-.slice

┣ user.slice

┃  ┗ user-1000.slice

┃     ┣ user@1000.service

┃     ┃ ┣ gpg-agent.service

┃     ┃ ┃  ┗ 1829 /usr/bin/gpg-agent --daemon

┃     ┃ ┗ init.scope

┃     ┃     ┗ 1822 /usr/lib/systemd/systemd --user

┃     ┃     ┗ 1825 (sd-pam)

┃     ┗ session-c1.scope

┃         ┣ 1414 /usr/bin/xdm -nodaemon

┃         ┣ 1831 icewm-session

┃         ┣ 1880 /usr/bin/dbus-launch --exit-with-session --sh-syntax

┃         ┣ 1881 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --se...

┃         ┣ 1900 /usr/libexec/polkit-mate-authentication-agent-1

┃         ┣ 1907 icewmbg

┃         ┣ 1908 icewm --notify

┃         ┣ 1912 /usr/libexec/at-spi-bus-launcher

┃         ┣ 1916 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/a...

┃         ┣ 1919 /usr/libexec/at-spi2-registryd --use-gnome-session

┃         ┗ 1929 icewmtray --notify

Mis à part la partie concernant la connexion de l'utilisateur, l'ouverture de la session IceWM en mode graphique est comparable à celle de la connexion en mode texte suivie de la commande startx.

Mais avant de démarrer la session l'unité prefdm avait recherché le gestionnaire de connexion à utiliser, comme indiqué plus haut, lookupdm a vérifié si le gestionnaire existe et en a extrait la commande /usr/bin/xdm ou /usr/bin/sddm, avec un argument -nodaemon.

Gestionnaire de connexion XDM (sans autologin)