Chapitre 3. Initialisation du système

# Chapitre 3. Initialisation du système

En tant qu’administrateur du système, il est sage que vous sachiez en gros comment le système Debian est démarré et configuré. Bien que les détails exacts figurent dans les fichiers sources des paquets installés et dans leurs documentations, c’est un peu pénible pour la plupart d’entre-nous.

Voici un aperçu succinct des points clé de l'initialisation du système Debian. Comme le système Debian évolue constamment, vous devriez vous référer à la dernière documentation.

- Le manuel Debian Linux Kernel Handbook est la principale source d'informations sur le noyau Debian.

- `bootup`(7) décrit le processus de démarrage du système basé sur `systemd` (dernières versions de Debian).

- `boot`(7) décrit le processus de démarrage du système basé sur UNIX System V version 4 (anciennes versions de Debian).

## 3.1. Aperçu du processus d’amorçage du système

Le système informatique subit plusieurs phases de processus d’amorçage (« boot strap process ») depuis l’événement de mise sous tension jusqu’à ce qu’il offre à l’utilisateur un système d’exploitation (OS) pleinement fonctionnel.

Pour des raison de simplicité, je limiterai la discussion à une plateforme PC typique avec l’installation par défaut.

Le processus d’amorçage typique est comme une fusée à quatre étages. Chaque étage de la fusée passe le contrôle du système à l’étage suivant.

- Section 3.1.1, « Étage 1 : UEFI »

- Section 3.1.2, « Étage 2 : le chargeur initial »

- Section 3.1.3, « Étage 3 : le système mini-Debian »

- Section 3.1.4, « Étage 4 : le système Debian normal »

Bien entendu, elles peuvent être configurées de manière différente. Par exemple, si vous avez compilé votre propre noyau, vous pouvez sautez l’étape avec le système mini-Debian. Ne supposez donc pas que c’est le cas sur votre système avant de l’avoir vérifié vous-même.

### 3.1.1. Étage 1 : UEFI

L’ interface micrologicielle extensible unifiée UEFI définit un gestionnaire de démarrage dans le cadre de la spécification UEFI. Lorsqu'un ordinateur est démarré, le gestionnaire de démarrage est le 1er étage du processus d’amorçage qui vérifie la configuration de démarrage et, en fonction de ses réglages, exécute alors le chargeur de démarrage ou le noyau du système d'exploitation spécifié (généralement le chargeur de démarrage). La configuration de démarrage est définie par les variables stockées dans la mémoire RAM non volatile, y compris les variables qui indiquent le chemin des systèmes de fichiers vers les chargeurs de démarrage ou les noyaux de système d’exploitation.

Une partition système EFI (ESP) est une partition de périphérique de stockage de données qui est utilisée dans les ordinateurs adhérant à la spécification UEFI. Accédée par le micrologiciel UEFI quand un ordinateur est démarré, elle stocke les applications UEFI et les fichiers dont ces applications ont besoin pour fonctionner, y compris les chargeurs de démarrage du système d'exploitation. (Sur le système patrimonial de PC, BIOS stocké dans le MBR peut être utilisé à la place.)

### 3.1.2. Étage 2 : le chargeur initial

Le chargeur de démarrage est le 2ème étage du processus de démarrage qui est lancé par l'UEFI. Il charge l'image du noyau du système et l'image initrd dans la mémoire et leur donne le contrôle. Cette image initrd est l'image du système de fichiers racine et sa prise en charge dépend du chargeur de démarrage utilisé.

Le système Debian utilise normalement le noyau Linux comme noyau système par défaut. L’image initrd pour le noyau Linux 5.x actuel est techniquement l’image initramfs (système de fichiers initial en RAM).

Il existe de nombreux chargeurs de démarrage et de nombreuses options de configuration disponibles.

Tableau 3.1. Liste des chargeurs initiaux

paquet | popularité | taille | initrd | chargeur initial | description
--- | --- | --- | --- | --- | ---
grub-efi-amd64 | I:436 | 142 | Pris en charge | GRUB UEFI | assez intelligent pour comprendre le partitionnement du disque et des systèmes de fichiers tels que vfat, ext4, …. (UEFI)
grub-pc | V:16, I:539 | 479 | Pris en charge | GRUB 2 | assez intelligent pour comprendre le partitionnement du disque et des systèmes de fichiers tels que vfat, ext4, …. (BIOS)
grub-rescue-pc | V:0, I:0 | 7323 | Pris en charge | GRUB 2 | images de secours amorçables de GRUB 2 (CD et disquettes) (versions PC/BIOS)
grml-rescueboot | V:0, I:1 | 36 | N/A | GRUB 2 plug-in | grml-rescueboot adds live Linux ISO images to the grub2 boot menu
syslinux | V:2, I:31 | 325 | Pris en charge | Isolinux | il comprend le système de fichiers ISO9660. C’est utilisé pour le CD d’amorçage.
syslinux | V:2, I:31 | 325 | Pris en charge | Syslinux | il comprend le système de fichiers MSDOS (FAT). Il est utilisé par la disquette d’amorçage.
loadlin | V:0, I:0 | 87 | Pris en charge | Loadlin | un nouveau système est démarré depuis le système FreeDOS/MSDOS.
mbr | V:0, I:3 | 47 | Non pris en charge | MBR par Neil Turton | c’est un logiciel libre qui se substitue au MBR de MSDOS. Il ne comprend que les partitions sur disques.

Pour le système UEFI, GRUB2 lit d’abord la partition ESP et utilise l’UUID spécifié pour `search.fs_uuid` dans « `/boot/efi/EFI/debian/grub.cfg` » pour déterminer la partition du fichier de configuration du menu GRUB2 « `/boot/grub/grub.cfg` ».

La partie principale du fichier de configuration du menu GRUB2 ressemble à ceci :

    menuentry 'Debian GNU/Linux' ... {
            load_video
            insmod gzio
            insmod part_gpt
            insmod ext2
            search --no-floppy --fs-uuid --set=root fe3e1db5-6454-46d6-a14c-071208ebe4b1
            echo    'Loading Linux 5.10.0-6-amd64 ...'
            linux   /boot/vmlinuz-5.10.0-6-amd64 root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 ro quiet
            echo    'Loading initial ramdisk ...'
            initrd  /boot/initrd.img-5.10.0-6-amd64
    }

Pour cette partie de `/boot/grub/grub.cfg`, cette entrée de menu signifie ce qui suit.

Tableau 3.2. La signification de l'entrée de menu de la partie ci-dessus de `/boot/grub/grub.cfg`

réglage | valeur
--- | ---
modules GRUB2 chargés | `gzio`, `part_gpt`, `ext2`
partition du système de fichiers racine utilisée | partition identifiée par `UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1`
chemin d'image du noyau dans le système de fichiers racine | `/boot/vmlinuz-5.10.0-6-amd64`
paramètre de démarrage du noyau utilisé | "`root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 ro quiet`"
chemin de l'image initrd dans le système de fichiers racine | `/boot/initrd.img-5.10.0-6-amd64`

On Debian system, "`/boot/grub/grub.cfg`" is managed by the installed GRUB package (e.g. `grub-efi-amd64`) and direct user modification to this file is deprecated. You should customize configuration files in "`/etc/grub.d/`" and "`/etc/default/grub`", instead. Then configure the GRUB configuration files and update NVRAM variables to automatically boot into Debian by:

    # dpkg-reconfigure grub-efi-amd64

| Astuce
You can show kernel boot log messages by removing "`quiet`" from the "`GRUB_CMDLINE_LINUX_DEFAULT`" value in "`/etc/default/grub`".

| Astuce
You can add GRUB splash background by placing its image file in "`/boot/grub/`".

See "`info grub`", `grub-install`(8), `grub-mkconfig`(8).

### 3.1.3. Étage 3 : le système mini-Debian

Le système mini-Debian est le troisième étage du processus d’amorçage lancée par le chargeur d’amorçage. Il lance le noyau du système avec son système de fichiers racine en mémoire. C’est un étage préparatoire facultatif du processus de démarrage.

| Note
Le terme « système mini-Debian » est utilisé par l’auteur pour décrire dans ce document ce 3ème étage du processus de démarrage. On désigne souvent ce système par système initrd. Un système semblable en mémoire est utilisé par l’installateur Debian.

Le script « `/init` » est exécuté en tant que premier programme sur le système de fichiers racine en mémoire. C’est un script de l’interpréteur de commandes qui initialise le noyau dans l’espace utilisateur et passe le contrôle au prochain étage. Ce système mini-Debian offre au système d’amorçage une flexibilité comme l’ajout de modules du noyau avant le processus de démarrage principal ou le montage du système de fichiers racine en mode chiffré.

- Le programme « `/init` » est un programme de script d’interpréteur si initramfs a été créé par `initramfs-tools`.

  - Vous pouvez interrompre cette partie du processus d’amorçage afin d’obtenir l’invite de l’interpréteur de l’administrateur en indiquant « `break=init` » etc. comme paramètre de démarrage du noyau. Consultez le script « `/init` » pour d’autres conditions d’interruption. Cet environnement d’interpréteur de commandes est suffisamment sophistiqué pour effectuer une bonne inspection du matériel de votre machine.

  - Les commandes disponibles avec ce système mini-Debian sont des commandes réduites et sont principalement fournies par un outil GNU appelé `busybox`(1).

- Le programme « `/init` » est un programme exécutable de `systemd` si initramfs a été créé par `dracut`.

  - Les commandes disponibles dans ce mini-système Debian forment un environnement `systemd`(1) réduit à l’essentiel.

| Attention
Vous devrez utiliser l’option « `-n` » de la commande `mount` lorsque vous êtes sur le système de fichiers en lecture seule.

### 3.1.4. Étage 4 : le système Debian normal

The normal Debian system is the 4th stage of the boot process which is started by the mini-Debian system. The system kernel for the mini-Debian system continues to run in this environment. The root filesystem is switched from the one on the memory to the one on the physical storage device.

Le programme init est le premier à être exécuté, assorti du PID=1, afin qu’il accomplisse son rôle de processus principal de démarrage de plusieurs programmes. Le chemin par défaut du programme init est « `/usr/sbin/init` » mais il peut être modifié en passant un paramètre de démarrage au noyau, comme suit : « `init=/chemin/vers/programme_init` ».

« `/usr/sbin/init` » est lié symboliquement à « `/lib/systemd/systemd` » depuis Debian 8 Jessie (publiée en 2015).

| Astuce
Il est possible de vérifier le niveau d’exécution actuel de la commande init du système avec la commande « `ps --pid 1 -f` ».

Tableau 3.3. Liste d’utilitaires d’amorçage initial pour le système Debian :

paquet | popularité | taille | description
--- | --- | --- | ---
`systemd` | V:903, I:978 | 10639 | démon `init`(8) basé sur des événements pour la concurrence (remplacement de `sysvinit`)
`cloud-init` | V:3, I:6 | 3231 | Systèmes d’initialisation pour les instances d’infrastructure de nuage
`systemd-sysv` | V:892, I:979 | 94 | les pages de manuel et liens nécessaires à `systemd` pour remplacer `sysvinit`
`init-system-helpers` | V:906, I:985 | 133 | outils d'aide pour basculer entre `sysvinit` et `systemd`
`initscripts` | V:17, I:69 | 203 | scripts pour initialiser et arrêter le système
`sysvinit-core` | V:3, I:3 | 369 | Utilitaires `init`(8) de type System-V
`sysv-rc` | V:35, I:73 | 91 | Mécanisme de changement de niveau de fonctionnement de type System-V
`sysvinit-utils` | V:715, I:999 | 106 | Utilitaires de type System-V (`startpar`(8), `bootlogd`(8), …)
`lsb-base` | V:250, I:363 | 12 | Linux Standard Base 3.2 fonctionnalité de script d’initialisation
`insserv` | V:41, I:73 | 132 | outil pour organiser la séquence de démarrage en utilisant les dépendances du script LSB de init.d
`kexec-tools` | V:1, I:5 | 320 | outil kexec pour le redémarrage par `kexec`(8) (redémarrage à chaud)
`systemd-bootchart` | V:0, I:0 | 131 | analyseur des performances du processus de démarrage
`mingetty` | V:0, I:2 | 36 | `getty`(8) en mode console uniquement
`mgetty` | V:0, I:0 | 315 | modem intelligent (« smart modem ») remplaçant de `getty`(8)

| Astuce
Vous trouverez des conseils actualisés pour accélérer le processus de démarrage sur Debian wiki:BootProcessSpeedup.

## 3.2. Rescue system

| Avertissement
Do not perform system administration tasks around the boot strap process without having a rescue system.

Availability of a rescue system enables us to perform challenging tasks such as:

- Booting a system from a broken boot loader installation
- Fixing a broken boot loader installation
- Extracting data from a broken unbootable system
- Editing filesystems, disk partitions, and LVM volumes involving the root filesystem

Typically, a rescue system is provided as a ISO image file and written to a removable storage media such as:

- USB flash drive prepared as Section 9.7.2, « Écrire directement sur le disque »

- CD / DVD prepared as Section 9.7.7, « Écriture directe sur CD/DVD-R/RW »

For simplicity, USB flash drive cases are mentioned as examples below but CD or DVD may be used as well.

| Astuce
You may need to change some UEFI NVRAM variables to boot arbitrary boot loaders on the removable storage media.

### 3.2.1. GRUB UEFI rescue system on USB

The GRUB UEFI rescue system with menu can be started by turning on system power with the "GRUB UEFI rescue system on USB" inserted.

This "GRUB UEFI rescue system on USB" is prepared by writing the Super Grub2 Disk ISO image to USB flash drive in advance.

In case of broken boot loader configuration by the installation of another operating system etc., you can fix this by:

- Start the GRUB UEFI rescue system to discover bootable installed systems automatically.

- Start the installed Debian system from the GRUB menu.

- At Linux root shell prompt:

      # dpkg-reconfigure grub-efi-amd64

| Note
The bootable GRUB rescue ISO image can be generated by following "`info grub-mkrescue`", too. It offers a CLI GRUB shell prompt but doesn't offer automatic discovery of bootable installed systems.

### 3.2.2. Linux live rescue system on USB

The Linux live rescue system can be started by turning on system power with the "Linux live rescue system on USB" inserted.

This "Linux live rescue system on USB" can be prepared by writing one of Linux live ISO images based on Debian to a USB flash drive in advance. Here are some examples of such Linux live images.

- Debian Live images

- Kali Linux Live

- Grml Live Linux

Here are some use cases of this Linux live rescue system:

- Fix the broken boot loader configuration caused by the installation of another operating system etc.:

  - Start the Linux live rescue system.

  - Mount the partition containing the root filesystem of the unbootable installed Debian system to "`/mnt`".

  - At Linux root shell prompt:

        # chroot /mnt dpkg-reconfigure grub-efi-amd64

- Fix the broken `dpkg` package:

  - Start the Linux live rescue system.

  - Mount the partition containing the root filesystem of the installed Debian system with the broken `dpkg` package to "`/mnt`".

  - At Linux root shell prompt:

        # dpkg --root /mnt -i /mnt/var/cache/apt/archives/dpkg_old_version_amd64.deb

- Perform normally prohibited changes such as filesystem operations to the installed system (see Section 9.6, « Astuces relatives au stockage des données »).

| Avertissement
Your GUI screen of the Linux live system may be locked after the inactivity.

| Astuce

- It's a good idea to set your password as soon as you start a Linux live system.

- You may set your password for example by "`sudo passwd user`" from the user's shell prompt on the Linux virtual consoles (see Section 1.1.6, « Consoles virtuelles »).

- Some Linux live systems may set their default "user/password": "Debian Live" = "user/live", "Kali Linux Live" = "kali/kali"

### 3.2.3. Linux live rescue system from GRUB

The Linux live rescue system can be started from the GRUB menu entry. The GRUB configuration for this is prepared by the following:

- Install the `gmrl-rescueboot` package

- Find a Linux live ISO image which has "`/boot/grub/loopback.cfg`" in its image.

  - ISO images mentioned in Section 3.2.2, « Linux live rescue system on USB » have "`/boot/grub/loopback.cfg`" in their image.

- Copy some of these Linux live ISO images to the "`/boot/grml/`" directory.

- Update GRUB menu by:

      # dpkg-reconfigure grub-efi-amd64

Upon turning on system power, the GRUB displays menu with candidates for Linux live rescue systems.

## 3.3. Systemd

### 3.3.1. Initialisation avec Systemd

Quand le système Debian démarre, `/usr/sbin/init` lié symboliquement avec `/usr/lib/systemd` est démarré comme processus de système init (`PID=1`) propriété du superutilisateur (`UID=0`). Consulter `systemd`(1).

Le processus d'initialisation de `systemd` génère des processus en parallèle en se basant sur les fichiers de configuration des unités (consulter `systemd.unit`(5)) qui sont écrits dans un style déclaratif au lieu du style procédural de type SysV.

Les processus engendrés sont placés dans des groupes de contrôle Linux individuels nommés d'après l'unité à laquelle ils appartiennent dans la hiérarchie privée de systemd (consulter cgroups et Section 4.7.5, « Caractéristiques de sécurité de Linux »).

Les unités pour le mode système sont chargés à partir du « Chemin de recherche d’unités système » décrit dans `systemd.unit`(5). Les principales sont les suivantes par ordre de priorité :

- « `/etc/systemd/system/*` » : unités du système créés par l’administrateur ;

- « `/run/systemd/system/*` » : unités d’exécution ;

- «`/lib/systemd/system/*` » : unités du système installées par le gestionnaire de paquets de la distribution.

Leurs interdépendances sont spécifiées par les directives « `Wants=` », « `Requires=` », « `Before=` », « `After=` », ... (consulter « MAPPING OF UNIT PROPERTIES TO THEIR INVERSES » dans `systemd.unit`(5)). Les contrôles de ressources sont également définis (consulter `systemd.resource-control`(5)).

Le suffixe du fichier de configuration de l'unité encode leurs types comme :

- *.service décrit le processus contrôlé et supervisé par `systemd`. Consulter `systemd.service`(5) ;

- *.device décrit le périphérique exposé dans `sysfs`(5) en tant qu'arborescence de périphériques `udev`(7). Consulter `systemd.device`(5) ;

- *.mount décrit le point de montage du système de fichiers contrôlé et supervisé par `systemd`. Consulter `systemd.mount`(5) ;

- *.automount décrit le point de montage automatique du système de fichiers contrôlé et supervisé par `systemd`. Consulter `systemd.automount`(5) ;

- *.swap décrit le périphérique ou le fichier d'échange contrôlé et supervisé par `systemd`. Consulter `systemd.swap`(5) ;

- *.path décrit le chemin supervisé par `systemd` pour l'activation basée sur le chemin. Consulter `systemd.path`(5) ;

- *.socket décrit le socket contrôlé et supervisé par `systemd` pour l’activation basée sur un socket. Consulter `systemd.socket`(5) ;

- *.timer décrit la minuterie contrôlée et supervisée par `systemd` pour l’activation basée sur une minuterie. Consulter `systemd.timer`(5) ;

- *.slice gère les ressources avec `cgroups`(7). Consulter `systemd.slice`(5) ;

- *.scope est créé de manière programmatique à l’aide des interfaces de bus de `systemd` pour gérer un ensemble de processus système. Consulter `systemd.scope`(5) ;

- *.target regroupe d'autres fichiers de configuration d’unité pour créer le point de synchronisation au démarrage. Consulter `systemd.target`(5).

Au démarrage du système (c’est-à-dire init), le processus `systemd` tente de démarrer le « `/lib/systemd/system/default.target` (normalement lié symboliquement lié à « `graphical.target` »). Tout d’abord, certaines unités cibles spéciales (consulter `systemd.special`(7)) telles que « `local-fs.target` », « `swap.target` » et « `cryptsetup.target` » sont extraites pour monter les systèmes de fichiers. Ensuite, d’autres unités cibles sont également extraites par les dépendances de l’unité cible. Pour plus d’informations, lisez `bootup`(7).

`systemd` offre des fonctionnalités de rétrocompatibilité. Les scripts de démarrage de style SysV dans « `/etc/init.d/rc[0123456S].d/[KS]nom` » sont toujours analysés et `telinit`(8) est traduit en demandes d’activation d’unité systemd.

| Attention
Les niveaux d’exécution émulés 2 à 4 sont tous liés symboliquement au même « `multi-user.target` ».

### 3.3.2. Connexion avec Systemd

Quand un utilisateur se connecte sur un système Debian à l’aide de `gdm3`(8), `sshd`(8), etc., `/lib/systemd/system --user` est démarré comme processus de gestionnaire de services de l’utilisateur, propriété de l’utilisateur correspondant (consulter `systemd`(1)).

Le gestionnaire `systemd` de services de l’utilisateur génère des processus en parallèle en se basant sur les fichiers de configuration des unités (consulter `systemd.unit`(5)) de style déclaratif et `user@.service`(5)).

Les unités pour le mode utilisateur sont chargées à partir du « Chemin de recherche d’unités de l’utilisateur » décrit dans `systemd.unit`(5). Les principales sont les suivantes par ordre de priorité :

- « `~/.config/systemd/user/*` » : unités de configuration de l’utilisateur ;

- « `/etc/systemd/user/*` » : unités de l’utilisateur créés par l’administrateur ;

- «`/run/systemd/user/*` » : unités d’exécution ;

- « `/lib/systemd/user/*` » : unités de l’utilisateur installées par le gestionnaire de paquets de la distribution.

Elles sont gérées de la même façon que dans la Section 3.3.1, « Initialisation avec Systemd ».

## 3.4. Messages du noyau

Le message d’erreur du noyau affiché sur la console peut être configuré en définissant son seuil :

    # dmesg -n3

Tableau 3.4. Liste des niveaux d’erreur du noyau

valeur du niveau d’erreur | nom du niveau d’erreur | signification
--- | --- | ---
0 | KERN_EMERG | le système est inutilisable
1 | KERN_ALERT | une action doit être entreprise immédiatement
2 | KERN_CRIT | conditions critiques
3 | KERN_ERR | conditions d’erreur
4 | KERN_WARNING | conditions d’avertissement
5 | KERN_NOTICE | condition normale mais significative
6 | KERN_INFO | information
7 | KERN_DEBUG | messages du niveau de débogage

## 3.5. Messages du système

Sous `systemd`, les messages du noyau et du système sont consignés par le service de journal `systemd-journald.service` (alias `journald`) soit comme données binaires persistantes dans « `/var/log/journal` » ou comme données binaires volatiles dans « `/run/log/journal/` ». Ces données binaires de journal sont accessibles avec la commande `journalctl`(1). Par exemple, vous pouvez afficher le journal du dernier démarrage avec :

    $ journalctl -b

Tableau 3.5. Liste de bribes de commande utilisant `journalctl`

Opération | bribe de commande
--- | ---
Afficher le journal des services système et du noyau depuis le dernier démarrage | « `journalctl -b --system` »
Afficher le journal des services de l'utilisateur actuel depuis le dernier démarrage | « `journalctl -b --user` »
Afficher le journal des tâches de « `$unit` » depuis le dernier démarrage | « `journalctl -b -u $unit` »
Afficher le journal des tâches de « `$unit` » (style « `tail -f` ») depuis le dernier démarrage | « `journalctl -b -u $unit -f` »

Sous `systemd`, l’utilitaire de journalisation du système `rsyslogd`(8) peut n’être pas installé. S’il est installé, il modifie son comportement pour lire les données binaires volatiles du journal (au lieu de la valeur par défaut avant systemd « `/dev/log` ») et pour créer des données ASCII permanentes traditionnelles de journal du système . Cela peut être personnalisé avec « `/etc/default/rsyslog` » et « `/etc/rsyslog.conf` » pour à la fois le fichier journal et l’affichage à l’écran. Voir `rsyslogd`(8) et `rsyslog.conf`(5). Voir aussi Section 9.3.2, « Analyseur de journaux ».

## 3.6. Gestion du système

`systemd` offre non seulement un système d’initialisation, mais aussi des opérations génériques de gestion du système avec la commande `systemctl`(1).

Tableau 3.6. Liste de bribes de commande typiques utilisant `journalctl`

Opération | bribe de commande
--- | ---
Lister toutes les types d’unités disponibles | « `systemctl list-units --type=aide` »
Lister toutes les unités cibles en mémoire | « `systemctl list-units --type=target` »
Lister toutes les unités de service en mémoire | « `systemctl list-units --type=service` »
Lister toutes les unités de périphérique en mémoire | « `systemctl list-units --type=device` »
Lister toutes les unités de montage en mémoire | « `systemctl list-units --type=mount` »
Lister toutes les unités de sockets en mémoire | « `systemctl list-sockets` »
Lister toutes les unités de minuterie en mémoire | « `systemctl list-timers` »
Démarrer « `$unit` » | « `systemctl start $unit` »
Stopper « `$unit` » | « `systemctl stop $unit` »
Recharger une configuration particulière à un service | « `systemctl reload $unit` »
Arrêter et démarrer tous les « `$unit` » | « `systemctl restart $unit` »
Démarrer « `$unit` » et arrêter tous les autres | « `systemctl isolate $unit` »
Basculer vers « `graphical` » (système GUI) | « `systemctl isolate graphical` »
Basculer vers « `multi-user` » (système CLI) | « `systemctl isolate multi-user` »
Basculer vers « `rescue` » (système CLI mono-utilisateur) | « `systemctl isolate rescue` »
Envoyer le signal kill à « `$unit` » | « `systemctl kill $unit` »
Vérifier si le service « `$unit` » est actif | « `systemctl is-active $unit` »
Vérifier si le service « `$unit` » est défaillant | « `systemctl is-failed $unit` »
Vérifier l’état de « `$unit|$PID|périphérique` » | "`systemctl status $unit|$PID|$device`"
Afficher les propriétés de « `$unit|$job` » | « `systemctl show $unit|$job` »
Réinitialiser « `$unit` » défaillant | « `systemctl reset-failed $unit` »
Lister les dépendances de tous les services d’unités | « `systemctl list-dependencies --all` »
Lister les fichiers d’unités installés sur le système | « `systemctl list-unit-files` »
Activer « `$unit` » (ajout de lien symbolique) | « `systemctl enable $unit` »
Désactiver « `$unit` » (suppression de lien symbolique) | « `systemctl disable $unit` »
Démasquer « `$unit` » (suppression de lien symbolique vers « `/dev/null` ») | « `systemctl unmask $unit` »
Masquer « `$unit` » (ajout de lien symbolique vers « `/dev/null` ») | « `systemctl mask $unit` »
Obtenir le réglage de la cible par défaut | « `systemctl get-default` »
Définir la cible par défaut à « `graphical` » (système à interface graphique) | « `systemctl set-default graphical` »
Définir la cible par défaut à « `multi-user` » (système en ligne de commande) | « `systemctl set-default multi-user` »
Afficher l’environnement de travail | « `systemctl show-environment` »
Définir la « `variable` » d’environnement de travail à « `valeur` » | « `systemctl set-environment variable=valeur` »
Rendre indéfini la « `variable` » d’environnement de travail | « `systemctl unset-environment variable` »
Recharger tous les démons et fichiers d’unité | « `systemctl daemon-reload` »
Arrêter le système | « `systemctl poweroff` »
Arrêter et redémarrer le système | « `systemctl reboot` »
Suspendre le système | « `systemctl suspend` »
Hiberner le système | « `systemctl hibernate` »

Ici, « `$unit` » dans les exemples ci-dessus peut être un nom d’unité unique (les suffixes tels que `.service` et `.cible` sont facultatifs) ou, dans de nombreux cas, des spécifications d’unité multiples (modèles génériques de type interpréteur « `*` », « `?` », « `[]` » en utilisant `fnmatch`(3) qui seront comparés aux noms principaux de toutes les unités actuellement en mémoire).

Les commandes de modification d’état du système dans les exemples ci-dessus sont classiquement précédées par la commande « `sudo` » pour obtenir les droits d’administration nécessaires.

La sortie de « `systemctl status $unit|$PID|$device` » utilise des points de couleur (« ● ») pour examiner l’état de l’unité d’un seul coup d’œil.

- Un « ● » blanc indique un état « inactif » ou « désactivation ».

- Un « ● » rouge indique un état « échec » ou « erreur ».

- Un « ● » vert indique un état « actif », « rechargement » ou « activation ».

## 3.7. Autres moniteurs du système

Voici une liste d’autres bribes de commandes de surveillance sous `systemd`. Veuillez lire les pages de manuel pertinentes, y compris `cgroups`(7).

Tableau 3.7. Liste d’autres bribes de commandes de surveillance sous `systemd`

Opération | bribe de commande
--- | ---
Afficher la durée de toutes les étapes d’initialisation | « `systemd-analyze time` »
Lister toutes les unités selon leurs temps d’initialisation | « `systemd-analyze blame` »
Charger et détecter les erreurs dans le fichier « `$unit` » | « `systemd-analyze verify $unit` »
Afficher des informations d’état d’exécution succinctes de l’utilisateur de la session de l’appelant | « `loginctl user-status` »
Afficher des informations succinctes sur l'état d'exécution de la session de l'appelant | « `loginctl user-status` »
Suivre le processus de démarrage selon les cgroups | « `systemd-cgls` »
Suivre le processus de démarrage selon les cgroups | « `ps xawf -eo pid,user,cgroup,args` »
Suivre le processus de démarrage selon les cgroups | Lire sysfs sous "`/sys/fs/cgroup/`"

## 3.8. Configuration du système

### 3.8.1. Nom de machine (« hostname »)

Le noyau gère le système nom_machine. L’unité centrale démarrée par `systemd-hostnamed.service` définit le nom de machine du système au démarrage au nom stocké dans « `/etc/hostname` ». Ce fichier doit contenir uniquement le nom de machine du système et non un nom de domaine pleinement qualifié.

Pour afficher le nom de la machine utilisée, lancez la commande `hostname` (1) sans paramètre.

### 3.8.2. Le système de fichiers

Les options de montage des systèmes ordinaires de fichiers de disque et en réseau sont définies dans « `/etc/fstab` ». Consulter `fstab`(5) et Section 9.6.7, « Optimisation du système de fichiers à l’aide des options de montage ».

La configuration du système de fichiers chiffré est définie dans « `/etc/crypttab` ». Consulter `crypttab`(5).

La configuration du RAID logiciel avec `mdadm`(8) est définie dans « `/etc/mdadm/mdadm.conf` ». Consulter `mdadm.conf`(5).

| Avertissement
Une fois tous les systèmes de fichiers montés, les fichiers temporaires se trouvant dans « `/tmp` », « `/var/lock` » et « `/var/run` » sont effacés lors de chaque démarrage du système.

### 3.8.3. Initialisation de l’interface réseau

Les interfaces réseau sont ordinairement initialisées dans « `networking.service` » pour l’interface `lo` et « `NetworkManager.service` » pour les autres interfaces sur les systèmes de bureau modernes de Debian sous `systemd`.

Voir Chapitre 5, Configuration du réseau pour savoir comment les configurer.

### 3.8.4. Initialisation du système d’infonuagique

L’instance du système d’infonuagique peut être lancée comme un clone des « Images officielles de Debian pour l’infonuagique » ou des images similaires. Pour une telle instance de système, les personnalités telles que le nom d’hôte, le système de fichiers, le réseautage, la régionalisation, les clés SSH, les utilisateurs et les groupes peuvent être configurées en utilisant des fonctionnalités fournies par les paquets `cloud-init` et `netplan.io` avec plusieurs sources de données telles que les fichiers placés dans l’image originelle du système et des données externes fournies lors de son amorçage. Ces paquets activent la configuration déclarative du système utilisant des données YAML.

Pour plus de détails, consulter « L’infonuagique avec Debian et ses descendants », la « documentation de Cloud-init » et la Section 5.4, « Configuration moderne de réseau pour l’infonuagique ».

### 3.8.5. Exemple de personnalisation pour ajuster le service sshd

Avec l'installation par défaut, de nombreux services réseau (consulter Chapitre 6, Applications réseau) sont démarrés comme processus démon après `network.target` au démarrage par `systemd`. Le démon « `sshd` » ne fait pas exception. Changeons donc cela pour un démarrage sur demande de « `sshd` » comme exemple de personnalisation.

Tout d’abord, désactivons l’unité de service du système installée.

     $ sudo systemctl stop sshd.service
     $ sudo systemctl mask sshd.service

Le système d’activation de socket à la demande des services Unix classiques passait par le superserveur `inetd` (ou `xinetd`). Sous `systemd`, l’équivalent peut être activé en ajoutant les fichiers de configuration d’unité *.socket et *.service.

`sshd.socket` pour indiquer un socket sur lequel écouté

    [Unit]
    Description=SSH Socket for Per-Connection Servers

    [Socket]
    ListenStream=22
    Accept=yes

    [Install]
    WantedBy=sockets.target

`sshd@.service` comme fichier de service correspondant de `sshd.socket`

    [Unit]
    Description=SSH Per-Connection Server

    [Service]
    ExecStart=-/usr/sbin/sshd -i
    StandardInput=socket

Puis rechargez.

     $ sudo systemctl daemon-reload

## 3.9. Le système udev

Le système udev fournit un mécanisme de découverte et d’initialisation automatique du matériel (consulter `udev`(7)) depuis le noyau 2.6 de Linux. Lors de la découverte de chaque périphérique par le noyau, le système udev lance un processus utilisateur qui utilise les informations provenant du système de fichiers sysfs (consulter Section 1.2.12, « procfs et sysfs »), charge les modules du noyau nécessaires pour sa prise en charge en utilisant le programme `modprobe`(8) (consulter la Section 3.10, « Initialisation des modules du noyau ») et crée les nœuds de périphérique en conséquence.

| Astuce

Si « `/lib/modules/kernel-version/modules.dep` » n’a pas été proprement créé par `depmod`(8) pour quelque raison, les modules peuvent ne pas être chargés par le système udev comme on le souhaiterait. Lancez « `depmod -a` » pour corriger ce problème.

Les nœuds de périphériques n’ont pas besoin d’être statiques pour les règles de montage se trouvant dans « `/etc/fstab` ». Vous pouvez utiliser UUID à la place de leur nom de périphérique tel que« `/dev/sda` » pour monter les périphériques. Consultez Section 9.6.3, « Accès à une partition en utilisant l’UUID ».

Comme le système udev est une cible quelque peu mouvante, je laisse les détails pour d’autres documentations et je ne donnerai ici qu’un minimum d’informations.

| Avertissement
N’essayez pas d’exécuter des programmes d’exécution longue tels qu’un script de sauvegarde avec `RUN` dans les règles d’udev comme mentionné dans `udev`(7). Veuillez créer un fichier `systemd.service`(5) adéquat et l’activer (consulter la Section 10.2.3.2, « Sauvegarde déclenchée par des évènements de montage »).

## 3.10. Initialisation des modules du noyau

Le programme `modprobe`(8) nous permet de configurer, depuis un processus utilisateur, un noyau Linux en cours d’exécution en ajoutant ou en supprimant des modules du noyau. Le système udev (consultez Section 3.9, « Le système udev ») en automatise l’appel afin d’aider à l’initialisation du module du noyau.

Il existe des modules non liés au matériel et des modules qui pilotent des éléments matériels particuliers comme les suivants qui demandent à être préchargés en les déclarant dans le fichier « `/etc/modules` » (consultez `modules`(5)).

- les modules TUN/TAP fournissent un périphérique de réseau virtuel point-à-point (TUN) et un périphérique de réseau virtuel Ethernet (TAP) ;

- les modules netfilter fournissent les fonctions de pare-feu netfilter (`iptables`(8), Section 5.7, « Infrastructure de netfilter ») ;

- le module du pilote du temporisateur de chien de garde.

Les fichiers de configuration du programme `modprobe`(8) se trouvent dans le répertoire « `/etc/modprobes.d/` » comme c’est expliqué dans `modprobe.conf`(5). (Si vous souhaitez que certains modules du noyau ne soient pas chargés automatiquement, vous pouvez les mettre en liste noire dans le fichier« `/etc/modprobes.d/blacklist` ».)

Le fichier « `/lib/modules/version/modules.dep` » généré par le programme `depmod`(8) décrit les dépendances des modules utilisés par le programme `modprobe`(8).

| Note
Si vous rencontrez des problèmes de chargement de modules lors du chargement des modules au démarrage ou avec `modprobe`(8), « `depmod -a` » peut résoudre ces problèmes en reconstruisant « `modules.dep` ».

Le programme `modinfo`(8) affiche des informations concernant les modules du noyau.

Le programme `lsmod`(8) formate de manière agréable le contenu de « `/proc/modules` », affichant quels sont les modules du noyau actuellement chargés.

| Astuce

Vous pouvez identifier le matériel exact installé sur votre système. Consultez Section 9.5.3, « Identification du matériel ».

Vous pouvez configurer le matériel au moment du démarrage pour activer les fonctionnalités désirées de ce matériel. Consultez Section 9.5.4, « Configuration matérielle ».

Vous pouvez probablement ajouter la prise en charge d’un périphérique particulier en recompilant le noyau. Consultez Section 9.10, « Le noyau ».

Chapitre 2. Gestion des paquets Debian |  | Chapitre 4. Contrôle d’authentification et d’accès