101.3 Leçon 1

Certification :

LPIC-1

Version :

5.0

Thème :

101 Architecture système

Objectif :

101.3 Changement de niveaux d’exécution / des cibles de démarrage de systemd et arrêt ou redémarrage du système

Leçon :

1 sur 1

Introduction

Un point caractéristique commun aux systèmes d’exploitation qui suivent les principes de conception d’Unix est l’utilisation de processus séparés pour contrôler les différentes fonctions du système. Ces processus appelés démons (ou, plus généralement, services) sont également chargés des fonctionnalités étendues sous-jacentes au système d’exploitation, comme les services d’application réseau (serveur HTTP, partage de fichiers, courrier électronique, etc.), les bases de données, la configuration à la demande, etc. Même si Linux utilise un noyau monolithique, de nombreux aspects bas niveau du système d’exploitation sont affectés par les démons, comme l’équilibrage de charge ou la configuration du pare-feu.

Le choix des démons à activer dépend de la vocation du système. Le jeu de démons actifs doit également être modifiable en cours d’exécution, de sorte que les services puissent être démarrés et arrêtés sans avoir à redémarrer l’ensemble du système. Pour résoudre ce problème, toutes les grandes distributions Linux proposent une forme d’outil de gestion des services pour contrôler le système.

Les services peuvent être contrôlés par des scripts shell ou par un programme et ses fichiers de configuration. La première méthode est implémentée par la norme SysVinit, également connue sous le nom de System V ou simplement SysV. La deuxième méthode est implémentée par systemd et Upstart. Historiquement, les gestionnaires de services basés sur SysV étaient les plus utilisés par les distributions Linux. De nos jours, les gestionnaires de services basés sur systemd sont plus courants dans la plupart des distributions Linux. Le gestionnaire de services est le premier programme lancé par le noyau au cours du processus de démarrage, son PID (numéro d’identification du processus) est donc toujours 1.

SysVinit

Un gestionnaire de services basé sur la norme SysVinit fournira un ensemble prédéfini d’états du système, appelés runlevels (niveaux d’exécution), et les fichiers de scripts du service correspondants à exécuter. Les runlevels sont numérotés de 0 à 6, et ils sont généralement affectés aux objectifs suivants :

Niveau 0: Arrêt du système.
Niveau 1, s ou single: Mode mono-utilisateur, sans réseau et autres fonctionnalités non-essentielles (pour la maintenance).
Niveaux 2, 3 ou 4: Mode multi-utilisateur. Les utilisateurs peuvent se connecter par la console ou par le réseau. Les niveaux 2 et 4 ne sont pas souvent utilisés.
Niveau 5: Mode multi-utilisateur. Il est équivalent au niveau 3, avec la connexion en mode graphique.
Niveau 6: Redémarrage du système.

Le programme chargé de la gestion des niveaux d’exécution et des démons/ressources associés est /sbin/init. Lors de l’initialisation du système, le programme init identifie le niveau d’exécution requis, défini par un paramètre du noyau ou dans le fichier /etc/inittab, et charge les scripts correspondants qui y sont référencés pour le niveau d’exécution donné. Chaque niveau d’exécution peut être associé à une série de fichiers de services, généralement des scripts dans le répertoire /etc/init.d/. Comme tous les niveaux d’exécution ne se valent pas selon les différentes distributions Linux, une description succincte de la finalité du niveau d’exécution peut également être trouvée dans les distributions basées sur SysV.

La syntaxe du fichier /etc/inittab utilise ce format :

id:niveaux:action:processus

L'`id` est un nom générique comportant jusqu’à quatre caractères, utilisé pour identifier l’entrée. L’entrée niveaux est une liste de numéros de niveaux d’exécution pour lesquels une action spécifiée doit être exécutée. Le terme action définit comment init va exécuter le processus indiqué par le terme processus. Les actions disponibles sont les suivantes :

boot: Le processus sera exécuté lors de l’initialisation du système. Le champ niveaux est ignoré.
bootwait: Le processus sera exécuté pendant l’initialisation du système et init attendra qu’il se termine pour continuer. Le champ niveaux est ignoré.
sysinit: Le processus sera exécuté après l’initialisation du système, quel que soit le niveau d’exécution. Le champ niveaux est ignoré.
wait: Le processus sera exécuté pour les niveaux d’exécution donnés et init attendra qu’il se termine pour continuer.
respawn: Le processus sera relancé s’il est interrompu.
ctrlaltdel: Le processus sera exécuté lorsque le processus init reçoit le signal SIGINT, déclenché lorsque la séquence de touches Ctrl+Alt+Del est actionnée.

Le niveau d’exécution par défaut — celui qui sera choisi si aucun autre n’est fourni comme paramètre du noyau — est également défini dans /etc/inittab, dans l’entrée id:x:initdefault. Le x est le nombre correspondant au niveau d’exécution par défaut. Ce nombre ne doit jamais être égal à 0 ou 6, étant donné que cela entraînerait l’arrêt ou le redémarrage du système dès la fin du processus de démarrage. Un fichier /etc/inittab typique est présenté ci-dessous :

# Niveau d'exécution par défaut
id:3:initdefault:

# Script de configuration exécuté au démarrage
si::sysinit:/etc/init.d/rcS

# Action effectuée au niveau d'exécution S (mono-utilisateur)
~:S:wait:/sbin/sulogin

# Configuration pour chaque niveau d'exécution
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6

# Action effectuée à la combinaison de touches ctrl+alt+del
ca::ctrlaltdel:/sbin/shutdown -r now

# Activer les consoles pour les niveaux d'exécution 2 et 3
1:23:respawn:/sbin/getty tty1 VC linux
2:23:respawn:/sbin/getty tty2 VC linux
3:23:respawn:/sbin/getty tty3 VC linux
4:23:respawn:/sbin/getty tty4 VC linux

# Activer le port série en plus pour le niveau d'exécution 3
# terminals ttyS0 and ttyS1 (modem) consoles
S0:3:respawn:/sbin/getty -L 9600 ttyS0 vt320
S1:3:respawn:/sbin/mgetty -x0 -D ttyS1

La commande telinit q devra être exécutée après chaque modification du fichier /etc/inittab. L’argument q (ou Q) indique à init de recharger sa configuration. Cette étape est cruciale pour éviter un arrêt du système suite à une mauvaise configuration dans /etc/inittab.

Les scripts utilisés par init pour configurer chaque niveau d’exécution sont rangés dans le répertoire /etc/init.d/. Chaque niveau d’exécution dispose d’un répertoire associé dans /etc/, nommé /etc/rc0.d/, /etc/rc1.d/, /etc/rc2.d/, etc., avec les scripts censés être exécutés au démarrage du niveau d’exécution correspondant. Étant donné qu’un même script peut être utilisé par différents niveaux d’exécution, les fichiers contenus dans ces répertoires ne sont que des liens symboliques vers les scripts réels dans /etc/init.d/. Par ailleurs, la première lettre du nom du lien dans le répertoire du niveau d’exécution indique si le service doit être démarré ou arrêté pour le niveau d’exécution correspondant. Un nom de lien commençant par la lettre K détermine que le service sera arrêté à l’entrée du niveau d’exécution (kill). S’il commence par la lettre S, le service sera démarré lors de l’entrée dans le niveau d`exécution (start). Le répertoire /etc/rc1.d/, par exemple, comportera de nombreux liens vers des scripts réseau commençant par la lettre K, étant donné que le niveau d’exécution 1 est le niveau d’exécution mono-utilisateur, sans connectivité réseau.

La commande runlevel indique le niveau d’exécution en cours pour le système. Cette commande affiche deux valeurs, la première est le niveau d’exécution précédent et la seconde correspond au niveau d’exécution actuel :

$ runlevel
N 3

La lettre N dans la sortie montre que le niveau d’exécution n’a pas changé depuis le dernier démarrage. Dans l’exemple, runlevel 3 correspond au niveau d’exécution en cours du système.

Le même programme init peut être utilisé pour basculer à chaud entre les niveaux d’exécution d’un système, sans qu’il soit nécessaire de redémarrer. La commande telinit peut également être utilisée pour basculer d’un niveau à l’autre. Par exemple, les commandes telinit 1, telinit s ou telinit S feront passer le système au niveau d’exécution 1.

systemd

Actuellement, systemd constitue la boîte à outils la plus utilisée pour gérer les ressources et les services du système, qui sont désignés sous le nom d’unités (units) par systemd. Une unité est composée d’un nom, d’un type et d’un fichier de configuration correspondant. À titre d’exemple, l’unité pour un processus de serveur _httpd (comme le serveur web Apache) sera httpd.service sur les distributions de la famille Red Hat et son fichier de configuration sera également appelé httpd.service (sur les distributions de la famille Debian, cette unité est appelée apache2.service).

On distingue sept types d’unités systemd :

service: Le type d’unité le plus courant, pour les ressources actives du système qui peuvent être initiées, interrompues et rechargées.
socket: Le type d’unité socket peut être un socket de système de fichiers ou un socket réseau. Toutes les unités socket ont une unité service correspondante, chargée lorsque le socket est sollicité.
device: Une unité device est associée à un périphérique matériel identifié par le noyau. Un périphérique ne sera considéré comme une unité systemd que s’il existe une règle udev à cet effet. Une unité device peut être utilisée pour résoudre les dépendances de configuration lorsque certains composants matériels sont détectés, étant donné que les propriétés de la règle udev peuvent être utilisées comme paramètres pour l’unité device.
mount: Une unité mount est une définition de point de montage dans le système de fichiers, similaire à une entrée dans /etc/fstab.
automount: Une unité automount est également une définition de point de montage dans le système de fichiers, mais montée automatiquement. Chaque unité automount dispose d’une unité mount correspondante, qui est lancée lors de l’accès au point de montage automount.
target: Une unité target (cible) est un regroupement d’autres unités, gérées comme une seule unité.
snapshot: Une unité snapshot est un état sauvegardé du gestionnaire systemd (non disponible sur toutes les distributions Linux).

La commande principale pour contrôler les unités systemd est systemctl. La commande systemctl est utilisée pour exécuter toutes les tâches liées à l’activation, la désactivation, l’exécution, l’interruption, la surveillance des unités, etc. Pour une unité fictive appelée unit.service, par exemple, les opérations systemctl les plus courantes seront :

systemctl start unit.service: Démarre unit.
systemctl stop unit.service: Arrête unit.
systemctl restart unit.service: Relance unit.
systemctl status unit.service: Affiche l’état de unit, y compris l’état d’activation.
systemctl is-active unit.service: Affiche active si `unit`est en état de marche ou inactive dans le cas contraire.
systemctl enable unit.service: Active unit, c’est-à-dire que unit se chargera lors de l’initialisation du système.
systemctl disable unit.service: unit ne démarrera pas avec le système.
systemctl is-enabled unit.service: Vérifie si unit démarre le système. La réponse est enregistrée dans la variable $?. La valeur 0 indique que unit démarre avec le système et la valeur 1 indique que unit ne démarre pas avec le système.

Note	Les installations plus récentes de systemd indiqueront plutôt la configuration d’une unité pour le démarrage. Par exemple : $ systemctl is-enabled apparmor.service enabled

Si aucune autre unité du même nom n’existe dans le système, le suffixe après le point peut être omis. Si, par exemple, il n’y a qu’une seule unité httpd de type service, alors un simple httpd est suffisant comme paramètre d’unité pour systemctl.

La commande systemctl peut également contrôler les cibles système (system targets). L’unité multi-user.target, par exemple, combine toutes les unités requises par l’environnement système multi-utilisateurs. Il est similaire au niveau d’exécution 3 dans un système basé sur SysV.

La commande systemctl isolate bascule entre différentes cibles. Ainsi, pour basculer manuellement vers la cible multi-user :

# systemctl isolate multi-user.target

Il existe des cibles correspondantes aux niveaux d’exécution SysV, en allant de runlevelO.target jusqu’à runlevel6.target. En revanche, systemd n’utilise pas le fichier /etc/inittab. Pour modifier la cible système par défaut, l’option systemd.unit peut être ajoutée à la liste des paramètres du noyau. Par exemple, pour utiliser multi-user.target comme cible standard, le paramètre du noyau sera systemd.unit=multi-user.target. Tous les paramètres du noyau peuvent être rendus persistants en modifiant la configuration du chargeur d’amorçage.

Une autre manière de changer la cible par défaut consiste à modifier le lien symbolique /etc/systemd/system/default.target de manière à ce qu’il pointe vers la cible souhaitée. La redéfinition du lien peut être effectuée par le biais de la commande systemctl :

# systemctl set-default multi-user.target

De même, on peut déterminer la cible de démarrage par défaut du système avec la commande suivante :

$ systemctl get-default
graphical.target

Comme pour les systèmes avec SysV, la cible par défaut ne doit jamais pointer vers shutdown.target, puisqu’elle correspond au niveau d’exécution 0 (arrêt).

Les fichiers de configuration associés à chaque unité se trouvent dans le répertoire /lib/systemd/system/. La commande systemctl list-unit-files affiche la liste de toutes les unités disponibles et indique si elles sont activées au démarrage du système. L’option --type sélectionnera uniquement les unités pour un certain type, comme dans systemctl list-unit-files --type=service et systemctl list-unit-files --type=target.

Les unités actives ou ayant été actives pendant la session système en cours peuvent être listées avec la commande systemctl list-units. Comme pour l’option list-unit-files, la commande systemctl list-units --type=service sélectionnera uniquement les unités de type service et la commande systemctl list-units --type=target sélectionnera uniquement les unités de type target.

Systemd est également chargé du déclenchement et de la réponse aux événements liés à l’alimentation. La commande systemctl suspend mettra le système en mode économique, en gardant les données actuelles en mémoire. La commande systemctl hibernate va copier toutes les données en mémoire sur le disque, de sorte que l’état actuel du système peut être récupéré après son extinction. Les actions associées à ces événements sont définies dans le fichier /etc/systemd/logind.conf ou dans des fichiers individuels à l’intérieur du répertoire /etc/systemd/logind.conf.d/. Cependant, cette fonctionnalité de systemd ne peut être utilisée que lorsqu’il n’y a aucun autre gestionnaire d’alimentation en cours d’exécution dans le système, comme le démon acpid. Le démon acpid est le principal gestionnaire d’énergie pour Linux et permet un ajustement plus fin des actions consécutives à des événements liés à l’alimentation, comme la fermeture du couvercle du portable, une batterie faible ou le niveau de charge de la batterie.

Upstart

Les scripts d’initialisation utilisés par Upstart se trouvent dans le répertoire /etc/init/. Les services du système peuvent être affichés avec la commande initctl list, qui indique également l’état actuel des services et, le cas échéant, leur PID.

# initctl list
avahi-cups-reload stop/waiting
avahi-daemon start/running, process 1123
mountall-net stop/waiting
mountnfs-bootclean.sh start/running
nmbd start/running, process 3085
passwd stop/waiting
rc stop/waiting
rsyslog start/running, process 1095
tty4 start/running, process 1761
udev start/running, process 1073
upstart-udev-bridge start/running, process 1066
console-setup stop/waiting
irqbalance start/running, process 1842
plymouth-log stop/waiting
smbd start/running, process 1457
tty5 start/running, process 1764
failsafe stop/waiting

Chaque action Upstart dispose de sa propre commande dédiée. Par exemple, la commande start peut être utilisée pour lancer un sixième terminal virtuel :

# start tty6

L’état actuel d’une ressource peut être vérifié avec la commande status :

# status tty6
tty6 start/running, process 3282

Quant à l’interruption d’un service, elle se fait avec la commande stop :

# stop tty6

Upstart n’utilise pas le fichier /etc/inittab pour définir les niveaux d’exécution, par contre les commandes traditionnelles runlevel et telinit permettent toujours de vérifier les niveaux d’exécution et d’alterner entre eux.

Note	Upstart a été développé pour la distribution Ubuntu Linux afin de faciliter le démarrage parallèle des processus. Ubuntu a cessé d’utiliser Upstart en 2015, date à laquelle la distribution est passée de Upstart à systemd.

Arrêt et redémarrage

Une commande très classique utilisée pour arrêter ou redémarrer le système est appelée shutdown, comme on peut s’y attendre. La commande shutdown ajoute des fonctions supplémentaires au processus de mise hors tension : elle envoie automatiquement un avertissement à tous les utilisateurs connectés à leurs sessions shell et empêche toute nouvelle connexion. La commande shutdown agit comme un intermédiaire aux procédures SysV ou systemd, c’est-à-dire qu’elle exécute l’action requise en appelant l’action correspondante dans le gestionnaire de services utilisé par le système.

Après l’exécution de shutdown, tous les processus reçoivent le signal SIGTERM, suivi du signal SIGKILL, puis le système s’arrête ou change de niveau d’exécution. Par défaut, lorsqu’aucune des options -h ou -r n’est utilisée, le système passe au niveau d’exécution 1, c’est-à-dire au mode mono-utilisateur. Pour modifier les options par défaut pour shutdown, la commande devra être exécutée avec la syntaxe suivante :

$ shutdown [option] time [message]

Seul le paramètre time est requis. Le paramètre time définit le moment où l’action requise sera exécutée, en acceptant les formats suivants :

hh:mm: Ce format spécifie le moment de l’exécution en heures et minutes.
+m: Ce format précise le nombre de minutes à attendre avant l’exécution.
now or +0: Ce format définit l’exécution immédiate.

Le paramètre message est le texte de l’avertissement envoyé dans toutes les sessions de terminal des utilisateurs connectés.

L’implémentation SysV permet de limiter les utilisateurs qui pourront redémarrer la machine en appuyant sur Ctrl+Alt+Del. Cela est possible en ajoutant l’option -a pour la commande shutdown à la ligne relative à ctrlaltdel dans le fichier /etc/inittab. En procédant ainsi, seuls les utilisateurs dont le nom d’utilisateur figure dans le fichier /etc/shutdown.allow pourront redémarrer le système grâce à la combinaison de touches Ctrl+Alt+Del.

La commande systemctl peut également être utilisée pour arrêter ou redémarrer la machine sur les systèmes basés sur systemd. Pour redémarrer le système, la commande systemctl reboot doit être utilisée. Pour arrêter le système, utilisez la commande systemctl poweroff. Les deux commandes nécessitent les droits root, étant donné que les utilisateurs normaux ne peuvent pas effectuer ce genre d’opération.

Note	Certaines distributions Linux associent `poweroff` et `reboot` à `systemctl` sous forme de commandes individuelles. Par exemple : $ sudo which poweroff /usr/sbin/poweroff $ sudo ls -l /usr/sbin/poweroff lrwxrwxrwx 1 root root 14 Aug 20 07:50 /usr/sbin/poweroff -> /bin/systemctl

Toutes les activités de maintenance ne requièrent pas l’arrêt ou le redémarrage du système. En revanche, lorsqu’il s’avère nécessaire de faire passer le système en mode mono-utilisateur, il est important d’avertir les utilisateurs connectés afin qu’ils ne soient pas affectés par une interruption brutale de leurs activités.

Tout comme la commande shutdown lors de l’arrêt ou du redémarrage du système, la commande wall est capable d’envoyer un message aux sessions de terminal de tous les utilisateurs connectés. Pour ce faire, il suffit à l’administrateur système de fournir un fichier ou d’écrire le message directement comme paramètre de la commande wall.

Exercices guidés

Comment la commande telinit peut-elle être utilisée pour redémarrer le système ?

Que deviendront les services liés au fichier /etc/rc1.d/K90network lorsque le système passe au niveau d’exécution 1 ?
En utilisant la commande systemctl, comment un utilisateur pourrait-il vérifier si l’unité sshd.service est en cours d’exécution ?
Sur un système basé sur systemd, quelle commande doit être exécutée pour permettre le lancement de l’unité sshd.service lors de l’initialisation du système ?

Exercices d’approfondissement

Sur un système basé sur SysV, supposons que le niveau d’exécution par défaut défini dans /etc/inittab est 3, mais le système démarre toujours au niveau d’exécution 1. Quelle est la cause probable de cette situation ?
Bien que le fichier /sbin/init soit présent dans les systèmes basés sur systemd, il n’est qu’un lien symbolique vers un autre fichier exécutable. Dans de tels systèmes, quel est le fichier pointé par /sbin/init ?
Comment peut-on vérifier la cible par défaut du système dans un système basé sur systemd ?
Comment peut-on annuler un redémarrage du système programmé avec la commande shutdown ?

Résumé

Cette leçon couvre les principaux outils utilisés pour gérer les services des distributions Linux. Les outils SysVinit, systemd et Upstart ont chacun leur propre approche pour contrôler les services et les états du système. La leçon aborde les sujets suivants :

Les services du système et leur rôle au sein du système d’exploitation.
Concepts et utilisation de base des commandes SysVinit, systemd et Upstart.
Démarrer, arrêter et redémarrer correctement les services du système et le système lui-même.

Voici les procédures et les commandes abordées :

Les commandes et les fichiers liés à SysVinit, comme init, /etc/inittab et telinit.
La commande principale de systemd : systemctl.
Les commandes d’Upstart : initctl, status, start, stop.
Les commandes traditionnelles de gestion de l’alimentation comme shutdown, et la commande wall.

Réponses aux exercices guidés

Comment la commande telinit peut-elle être utilisée pour redémarrer le système ?

La commande telinit 6 va basculer vers le niveau d’exécution 6 et donc redémarrer le système.
Que deviendront les services liés au fichier /etc/rc1.d/K90network lorsque le système passe au niveau d’exécution 1 ?

Du fait de la lettre K au début du nom du fichier, les services correspondants seront arrêtés.
En utilisant la commande systemctl, comment un utilisateur pourrait-il vérifier si l’unité sshd.service est en cours d’exécution ?

Avec la commande systemctl status sshd.service ou systemctl is-active sshd.service.
Sur un système basé sur systemd, quelle commande doit être exécutée pour permettre le lancement de l’unité sshd.service lors de l’initialisation du système ?

La commande systemctl enable sshd.service, exécutée par root.

Réponses aux exercices d’approfondissement

Sur un système basé sur SysV, supposons que le niveau d’exécution par défaut défini dans /etc/inittab est 3, mais le système démarre toujours au niveau d’exécution 1. Quelle est la cause probable de cette situation ?

Les paramètres 1 ou S peuvent figurer dans la liste des paramètres du noyau.
Bien que le fichier /sbin/init soit présent dans les systèmes basés sur systemd, il n’est qu’un lien symbolique vers un autre fichier exécutable. Dans de tels systèmes, quel est le fichier pointé par /sbin/init ?

Le binaire systemd principal : /lib/systemd/systemd.
Comment peut-on vérifier la cible par défaut du système dans un système basé sur systemd ?

Le lien symbolique /etc/systemd/system/default.target pointera vers le fichier unité défini comme cible par défaut. La commande systemctl get-default peut également être utilisée.
Comment peut-on annuler un redémarrage du système programmé avec la commande shutdown ?

La commande shutdown -c doit être utilisée.