EEIJ

Païou : Mandriva Linux depuis 2002. Aujourd'hui, c'est Mageia Linux


Sommaire


Conforme à XHTML 1.0 Strict Conforme à CSS!

On se lasse de tout, sauf de comprendre.
Attribué à Virgile.

Démarrage de Linux avec Systemd

Historique

01 octobre 2011 : Ébauche de cette page.
11 septembre 2012 : actualisation avec cauldron (mageia 3)
20 novembre 2013 : refonte et actualisation avec cauldron (mageia 4)

Difficulté

Pour : linuxien averti.

 Introduction

La page : Démarrage de l'ordinateur a présenté la partie commune à tous les systèmes d'exploitation.

Dans la présente page, vous trouverez la suite, c'est-à-dire le démarrage de Linux.
System V (cinq) a longtemps été le système de démarrage de Linux, donc de Mandriva et également de Mageia 1.
Mageia 2 et les suivants utilisent maintenant systemd pour démarrer le système linux.

 Le noyau linux

Vous avez vu, sur la page précédente, que la noyau linux a pris la relève du BIOS, grâce au chargeur de démarrage (GRUB par exemple).
Le noyau initialise différents composants matériels (processeur, périphériques, carte graphique ...)
Le noyau lance /sbin/init (en réalité /usr/sbin/init) mais, avec systemd, il s'agit d'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.

Haut

 Le processus /sbin/init (/usr/lib/systemd/systemd)

Le noyau exécute donc le processus numéro 1, /sbin/init qui pointe en réalité vers /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 (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/ :

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

Haut

 Les unités

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

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.

Haut

 Syntaxe des fichiers .service

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 ...)
Pour les curieux, survolez : le fichier lightdm.service (lightdm-1.11.2-1.mga5)

[Unit]
Description=Light Display Manager
Documentation=man:lightdm(1)
Conflicts=getty@tty1.service
After=systemd-user-sessions.service getty@tty1.service plymouth-quit.service

[Service]
ExecStart=/usr/sbin/lightdm
Restart=Always
IgnoreSIGPIPE=no
BusName=org.freedesktop.DisplayManager

[Install]
Alias=display-manager.service

Quelques précisions

Conflicts= l'unité ne doit pas être démarrée si une ou plusieurs autres sont encore en cours d'exécution.

Requires= le fonctionnement de cette unité dépend d'une ou de plusieurs autres unités qui doivent également démarrer. Requires ne détermine pas l'ordre dans lequel les unités doivent être démarrées ou arrêtées. Elles peuvent démarrer simultanément.
Si le démarrage d'une ou de plusieurs autres unités demandées échoue, cette unité sera désactivée.

Wants= comme Requires, mais ici le fonctionnement d'une autre unité est optionnel.

Before, After= configure l'ordre dans lequel les unités doivent être démarrées.
Si une unité foo.service contient un argument Before=bar.service et si les deux unités sont demandées, le démarrage de bar.service est retardé jusqu'à ce que foo.service est mis en marche.

ExecStart= commande à exécuter pour démarrer

ExecStop= commande à exécuter pour arrêter

Restart= précise comment un service peut être redémarré

BusName il s’agit d’un service D-Bus

Alias la présente unité peut également être installée en invoquant le nom de l'unité alias

Haut

 Syntaxe du fichier .socket

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 ...)
Pour les curieux, survolez : le fichier systemd-journald.socket (systemd-units-208-15.mga5)

[Unit]
Description=Journal Socket
Documentation=man:systemd-journald.service(8) man:journald.conf(5)
DefaultDependencies=no
Before=sockets.target
IgnoreOnIsolate=yes

[Socket]
ListenStream=/run/systemd/journal/stdout
ListenDatagram=/run/systemd/journal/socket
ListenDatagram=/dev/log
SocketMode=0666
PassCredentials=yes
PassSecurity=yes
ReceiveBuffer=8M

Haut

 Syntaxe du fichier .target

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.

Pour les curieux, survolez : le fichier graphical.target (systemd-units-208-15.mga5)

[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
After=multi-user.target
Conflicts=rescue.target
Wants=display-manager.service
AllowIsolate=yest

Quelques précisions

Requires= le fonctionnement de cette unité dépend d'une autre unité qui doit également être démarrée.
Conflicts= cette unité ne doit pas être démarrée si une ou plusieurs autres unités sont en cours d'exécution.
After= cette unité doit être démarrée après une ou plusieurs autres. À la différence de Requires=, After= n'implique pas que ces unités doivent encore tourner.
AllowIsolate= cette unité peut éventuellement être lancée manuellement avec une commande :
systemctl isolate graphical.target

Haut

 Examen de quelques fichiers d'unités

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 :

L'unité default.target

Elle est définie par un fichier (etc)/default.target et un répertoire (etc)/default.target.wants

Le fichier (etc)/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.

Le répertoire (etc)/default.target.wants

Il contient deux liens vers → (usr)/systemd-readahead-collect.service et → (usr)/systemd-readahead-replay.service

En résumé

L'unité default.target renvoie vers l'unité qui doit effectivement être démarrée, en l’occurrence runlevel5.target. Mais il faut également que les deux services spécifiés soient démarrés.

L'unité runlevel3.target (systemd-units-208-15.mga5)

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 contient un un lien vers → (usr)/systemd-update-utmp-runlevel.service

En résumé

Dans le mode console (runlevel3), le service systemd-update-utmp-runlevel doit être activé, puis runlevel3.target renvoie vers l'unité multi-user.target

L'unité runlevel5.target (systemd-units-208-15.mga5)

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 contient un lien vers → (usr)/systemd-update-utmp-runlevel.service

En résumé

Dans le mode graphique (runlevel5), le service systemd-update-utmp-runlevel doit être activé, puis runlevel5.target renvoie vers l'unité graphical.target

L'unité multi-user.target (systemd-units-208-15.mga5)

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

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

Ce répertoire contient plusieurs liens symboliques : acpid.service, avahi-daemon.service, cpupower.service, crond.service, remote-fs.target, shorewall.service, shorewall6.service, pointant tous vers des fichiers du même nom dans le répertoire → (usr)/

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

Ce répertoire contient également plusieurs liens symboliques : getty.target, rpcbind.target, system-ask-password-wall.path, systemd-logind.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.

Haut

L'unité graphical.target (systemd-units-208-15.mga5)

Elle est définie par un fichier (usr)/graphical.target.

Le fichier (usr)/graphical.target

L'unité graphical.target

En résumé

Le fichier (usr)/graphical.target nous dit que l'unité (usr)/multi-user.target est nécessaire et qu'elle doit déjà être en cours d'exécution, que, si possible, le service (usr)/display-manager doit tourner, mais que (usr)/rescue.target ne doit pas être démarré.

Haut

L'unité basic.target (systemd-units-208-15.mga5)

Cette unité est définie par un fichier (usr)/basic.target et deux répertoires (etc)/basic.target.wants et (usr)/basic.target.wants.

Le fichier (usr)/basic.target

L'unité basic.target

Le répertoire (etc)/basic.target.wants

Ce répertoire contient deux liens symboliques vers : → (usr)/ip6tables.service, → (usr)/iptables.service

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

Ce répertoire est vide au niveau du paquetage.

En résumé

Le fichier basic.target nous dit que l'unité sysinit.target est nécessaire, que les unités sockets.target, timers.target, paths.target et slices.target sont souhaitées et qu'elles doivent toutes déjà être activées.
Les deux répertoires basic.target.wants nous disent que plusieurs autres services sont nécessaires.

Haut

Les unités display-manager.service et prefdm.service (systemd-units-208-15.mga5)

Les unités du type .service ne nécessitent qu'un seul fichier de configuration. Le fichier (usr)/display-manager.service pointe vers le fichier → (usr)/prefdm.service.

L'unité prefdm.service

Haut

 Les outils pour analyser

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

Pour des informations plus complètes, voyez la page : Archlinux

systemctl list-units

Elle permet de lister toutes les unités présentes sur le systèmes sans renseigner sur la chronologie.
Les commandes suivantes peuvent être exécutées :
systemctl list-units : liste les unités actives
systemctl list-units -a (ou --all) : liste toutes les unités pouvant être démarrées, actives ou non
systemctl list-units -t service (ou --type=service) : liste tous les services actifs

Survolez : extraits de la sortie de systemctl list-units pour une installation minimale (xdm, IceWM-light)
UNIT                                    LOAD   ACTIVE SUB     DESCRIPTION
sys-devices-pnp0-00:09-tty-ttyS0.device loaded active plugged /sys/devices/pnp0/00:09/tty/ttyS0
-.mount                                 loaded active mounted /
systemd-ask-password-plymouth.path      loaded active waiting Forward Password Requests to Plymouth Directory Watch
prefdm.service                          loaded active running Display Manager
basic.target                            loaded active active  Basic System
systemd-journald.socket                 loaded active running Journal Socket

Avec la signification des 5 colonnes :

  • UNIT : Le nom d'une unité de systemd,
  • LOAD : information indiquant si l'unité a été chargée correctement,
  • ACTIVE : état général d'activation d'une unité,
  • SUB : état d'activation (dépend du type de l'unité : waiting, plugged, mounted, running, exited, listening, active ...),
  • DESCRIPTION : description brève.
systemctl show

systemctl show multi-user.target : pour voir toutes les caractéristiques d'une unité.
systemctl show -p "Wants" multi-user.target : pour voir quels services sont démarrés par une cible donnée (par ex. multi-user.target).
À la place de Wants, vous pouvez également demander "WantedBy", "Requires", "RequiredBy", "Conflicts", "ConflictedBy", "Before", "After".

systemd-cgls

Sous UNIX, un processus peut créer un fork (le programme relance une nouvelle instance, en tâche de fond). Il sort alors complètement de la supervision du processus qui l’a lancé. Prenons, par exemple, un script CGI lancé par un serveur Web. Lorsqu’il crée un fork, il devient orphelin et est rattaché au processus de PID 1. L’arrêt du serveur Web ne le concerne pas, et aucun script système n’est en mesure de le retrouver automatiquement pour le couper.

Le noyau Linux implémente un mécanisme appelé cgroups (control groups) qui permet de créer un groupe et d’y placer des processus. Tout processus créé au sein d’un cgroup y reste, résolvant ainsi notre problème de CGI fou.

La commande systemd-cgls permet d'afficher, de manière récursive, le contenu des groupes de contrôle (cgroup).

Survolez : la sortie de systemd-cgls pour une installation minimale (xdm, IceWM-light)
┣1 /sbin/init
┣user.slice
┃  ┗user-500.slice
┃   ┣session-c1.scope
┃   ┃ ┣  925 -:0
┃   ┃ ┣ 2100 /bin/bash /usr/bin/starticewm
┃   ┃ ┣ 2153 /usr/bin/perl /usr/bin/mgaapplet
┃   ┃ ┣ 2164 /usr/libexec/polkit-mate-authentication-agent-1
┃   ┃ ┣ 2166 /usr/bin/perl /usr/bin/net_applet
┃   ┃ ┣ 2176 s2u --daemon=yes
┃   ┃ ┣ 2179 /usr/bin/icewm-session
┃   ┃ ┣ 2185 icewmbg
┃   ┃ ┣ 2186 icewm
┃   ┃ ┣ 2251 /bin/xterm
┃   ┃ ┣ 2279 bash
┃   ┃ ┣ 2456 /bin/xterm
┃   ┃ ┣ 2484 bash
┃   ┃ ┣ 2522 su
┃   ┃ ┣ 2528 bash
┃   ┃ ┣10238 su
┃   ┃ ┣10244 bash
┃   ┃ ┗10373 systemd-cgls
┃   ┗user@500.service
┃     ┣2098 /usr/lib/systemd/systemd --user
┃     ┗2099 (sd-pam)

				
┗system.slice
 ┣systemd-journald.service
 ┃ ┗407 /usr/lib/systemd/systemd-journald
 ┣systemd-udevd.service
 ┃ ┗456 /usr/lib/systemd/systemd-udevd
 ┣alsa-state.service
 ┃ ┗555 /usr/sbin/alsactl -s -n 19 -c rdaemon
 ┣avahi-daemon.service
 ┃ ┣602 avahi-daemon: running [test.local]
 ┃ ┗605 avahi-daemon: chroot helper
 ┣acpid.service
 ┃ ┗604 /usr/sbin/acpid
 ┣systemd-logind.service
 ┃ ┗606 /usr/lib/systemd/systemd-logind
 ┣dbus.service
 ┃ ┗607 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfi...
 ┣crond.service
 ┃ ┗609 /usr/sbin/crond -n
 ┣prefdm.service
 ┃ ┣615 /usr/bin/xdm -nodaemon
 ┃ ┗788 /etc/X11/X -deferglyphs 16 -auth /var/lib/xdm/authdir/authfiles/A:0...
 ┣network.service
 ┃ ┣ 832 /sbin/ifplugd -I -b -i enp0s4
 ┃ ┣ 934 /sbin/ifplugd -I -b -i wlan0
 ┃ ┗1090 dhclient -1 -q -lf /var/lib/dhclient/dhclient--enp0s4.lease -pf /v...
 ┣mandi.service
 ┃ ┗1932 /usr/sbin/mandi -d
 ┣polkit.service
   ┗2178 /usr/lib/polkit-1/polkitd --no-debug
ps waxf -eo 'user,pid,cgroup,command'

Cette commande liste les processus actifs et présente le résultat selon la syntaxe donnée par l'option -eo

Survolez : extrait de la sortie de ps waxf -eo 'user,pid,cgroup,args'
USER   PID CGROUP                                    COMMAND
root     2 -                                         [kthreadd]
root     3 -                                           \_ [ksoftirqd/0]
root          toute une série de processus du noyau
root     1 name=systemd:/system.slice                /sbin/init
root   407 name=systemd:/system.slice/systemd-journald.service /usr/lib/systemd/systemd-journald
root   458 name=systemd:/system.slice/systemd-udevd.service /usr/lib/systemd/systemd-udevd
root   549 name=systemd:/system.slice/alsa-state.service /usr/sbin/alsactl -s -n 19 -c rdaemon
avahi  602 name=systemd:/system.slice/avahi-daemon.service avahi-daemon: running [test.local]
avahi  608 name=systemd:/system.slice/avahi-daemon.service  \_ avahi-daemon: chroot helper
root    606 name=systemd:/system.slice/acpid.service /usr/sbin/acpid
root    607 name=systemd:/system.slice/systemd-logind.service /usr/lib/systemd/systemd-logind
499     609 name=systemd:/system.slice/dbus.service /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
root    611 name=systemd:/system.slice/crond.service /usr/sbin/crond -n
root    616 name=systemd:/system.slice/prefdm.service /usr/bin/xdm -nodaemon
root    659 name=systemd:/system.slice/prefdm.service  \_ /etc/X11/X -deferglyphs 16 -auth /var/lib/xdm/authdir/authfiles/A:0-BbK1xs
root    758 name=systemd:/user.slice/user-500.slice/session-c1.scope  \_ -:0
paiiou 2099 name=systemd:/user.slice/user-500.slice/session-c1.scope      \_ /bin/bash /usr/bin/starticewm
paiiou 2152 name=systemd:/user.slice/user-500.slice/session-c1.scope          \_ /usr/bin/perl /usr/bin/mgaapplet
paiiou 2173 name=systemd:/user.slice/user-500.slice/session-c1.scope          \_ /usr/bin/icewm-session
paiiou 2176 name=systemd:/user.slice/user-500.slice/session-c1.scope              \_ icewmbg
paiiou 2177 name=systemd:/user.slice/user-500.slice/session-c1.scope              \_ icewm
paiiou 2207 name=systemd:/user.slice/user-500.slice/session-c1.scope                  \_ /bin/xterm
paiiou 2249 name=systemd:/user.slice/user-500.slice/session-c1.scope                      \_ bash
root   2296 name=systemd:/user.slice/user-500.slice/session-c1.scope                          \_ su
...
systemd-analyze

Cet outil permet d'analyser le démarrage :

Survolez : extrait de la sortie de systemd-analyze blame
5.804s shorewall.service
4.859s shorewall6.service
4.651s network-up.service
 ...
  23ms fedora-wait-storage.service
  14ms systemd-update-utmp-runlevel.service
   6ms systemd-readahead-done.service
Haut

 Démarrage de systemd

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

 Quelques définitions préalables

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.

 Avant une session utilisateur

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.

Pour les curieux, survolez : analyse avec dmesg

L'outil dmesg donne des informations très détaillées sur le processus de démarrage, avec sa chronologie.
dmesg | grep systemd > dmesg_systemd.txt

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.

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) :

┣1 /sbin/init
┗system.slice
 ┣systemd-journald.service
 ┃ ┗407 /usr/lib/systemd/systemd-journald
 ┣systemd-udevd.service
 ┃ ┗462 /usr/lib/systemd/systemd-udevd
 ┣alsa-state.service
 ┃ ┗503 /usr/sbin/alsactl -s -n 19 -c rdaemon
 ┣acpid.service
 ┃ ┗583 /usr/sbin/acpid
 ┣avahi-daemon.service
 ┃ ┣584 avahi-daemon: running [test.local]
 ┃ ┗586 avahi-daemon: chroot helper
 ┣dbus.service
 ┃ ┗588 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfi...
 ┣systemd-logind.service
 ┃ ┗589 /usr/lib/systemd/systemd-logind
 ┣crond.service
 ┃ ┗596 /usr/sbin/crond -n
 ┣network.service
 ┃ ┣ 797 /sbin/ifplugd -I -b -i enp0s4
 ┃ ┗ 996 dhclient -1 -q -lf /var/lib/dhclient/dhclient--enp0s4.lease -pf /v...
 ┣mandi.service
 ┃ ┗1967 /usr/sbin/mandi -d
 ┣polkit.service
   ┗2178 /usr/lib/polkit-1/polkitd --no-debug

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

 ┣prefdm.service
 ┃ ┣ 602 /usr/bin/xdm -nodaemon
 ┃ ┗ 642 /etc/X11/X -deferglyphs 16 -auth /var/lib/xdm/authdir/authfiles/A:0...
 ┣polkit.service
 ┃ ┗2086 /usr/lib/polkit-1/polkitd --no-debug

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.

Haut

 Instance utilisateur

Depuis la version 206 de systemd, le mécanisme des instances utilisateur a changé. Maintenant le module pam_systemd.so démarre une instance de systemd avec le login du premier utilisateur qui se connecte (50x avec Mageia). Un user.slice et un user-50x.slice sont automatiquement créés.

L'extrait de systemd-cgls montre le groupe de process (tranche) user.slice, le sous-groupe user-500.slice avec l'unité user@500.service qui lance les process /usr/lib/systemd/systemd --user et (sd-pam) :

┣1 /sbin/init
┗user.slice
  ┗user-500.slice
    ┗user@500.service
      ┣2098 /usr/lib/systemd/systemd --user
      ┗2099 (sd-pam)
Haut

 Session utilisateur

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

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 :

┣1 /sbin/init
┗user.slice
  ┗user-500.slice
   ┗session-c1.scope

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

Haut

 Session en mode texte

Si l'utilisateur a décidé de démarrer en mode texte, dmesg nous informe que :

L'unité getty@tty1.service exécute /sbin/agetty, en tant que premier process lancé dans une session.

Les pages man de agetty et login nous disent que : .

Connexion de l'utilisateur

Dans l'exemple ci-dessous, l'utilisateur georges se connecte et lance la commande systemd-cgls

┣1 /sbin/init
┗user.slice
  ┗user-500.slice
   ┗session-c1.scope
    ┣ 609 login -- georges
    ┣1978 -bash
    ┗2022 systemd-cgls

Connexion de l'utilisateur suivie de la commande startx

Dans l'exemple ci-dessous, l'utilisateur georges se connecte et lance la commande startx, puis la commande systemd-cgls dans un terminal de IceWM :

┣1 /sbin/init
┗user.slice
  ┗user-500.slice
   ┗session-c1.scope
    ┣ 609 login -- georges
    ┣1978 -bash
    ┣2018 /bin/sh /usr/bin/startx
    ┣2039 xinit /etc/X11/xinit/xinitrc -- vt1 -auth /home/georges/.servera...
    ┣2040 /etc/X11/X :0 vt1 -auth /home/georges/.serverauth.2018 -defergly...
    ┣2043 /bin/bash /usr/bin/starticewm
    ┣2072 /usr/bin/perl /usr/bin/mgaapplet
    ┣2089 /usr/bin/icewm-session
    ┣2090 icewmbg
    ┣2091 icewm
    ┣2096 s2u --daemon=yes
    ┣2107 /usr/bin/xterm
    ┣2135 -bash
    ┗2165 systemd-cgls
Haut

 Session en mode graphique

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

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.

Avec systemd-cgls 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, les unités prefdm.service et polkit.service.

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

Voici le contenu de session-c1.scope :

┣1 /sbin/init
┗user.slice
  ┗user-500.slice
   ┗session-c1.scope
    ┣ 740 -:0
    ┣2043 /bin/bash /usr/bin/starticewm
    ┣2072 /usr/bin/perl /usr/bin/mgaapplet
    ┣2068 /usr/bin/perl /usr/bin/net_applet
    ┣2069 /usr/libexec/polkit-mate-authentication-agent-1
    ┣2089 /usr/bin/icewm-session
    ┣2090 icewmbg
    ┣2091 icewm
    ┣2096 s2u --daemon=yes
    ┣2107 /bin/xterm
    ┣2135 -bash
    ┗2165 systemd-cgls

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 le session l'unité prefdm a recherché le gestionnaire de connexion à utiliser :

/etc/X11/prefdm

Le rôle de prefdm est de lire deux variables qui indiquent quels sont : le gestionnaire de connexion et le bureau que vous avez choisis. Pour ceci :

/etc/X11/lookupdm

Le rôle de lookupdm 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. Pour ceci :

Ainsi lookupdm a pu définir quel gestionnaire de connexion sera utilisé (celui que vous avez choisi ou un gestionnaire de remplacement) et a trouvé la commande à exécuter, pour lancer le gestionnaire.
Cette commande sera l'une des suivantes : /usr/bin/xdm, /usr/bin/slim, /usr/sbin/lxdm, /usr/sbin/gdm ou /usr/bin/kdm, avec un argument -nodaemon.


Gestionnaire de connexion XDM (sans autologin) Travaux

Cette page étant déjà suffisamment longue, vous trouverez le gestionnaire XDM Cliquez.

Gestionnaire de connexion LXDM (avec ou sans autologin) Travaux

Cette page étant déjà suffisamment longue, vous trouverez le gestionnaire LXDM Cliquez.

Gestionnaire de connexion lightdm (avec ou sans autologin) Travaux

Cette page étant déjà suffisamment longue, vous trouverez le gestionnaire lightdm Cliquez.

Haut