Résolution des problèmes de démarrage Systemd : Problèmes courants et solutions

Les problèmes de démarrage sous Linux peuvent être parmi les plus frustrants pour tout administrateur système ou utilisateur avancé. Lorsque votre système ne se met pas en ligne, la première étape consiste souvent à identifier ce qui empêche le processus de démarrage de se terminer avec succès. En tant que gestionnaire de système et de services principal pour les distributions Linux modernes, systemd joue un rôle central dans l'orchestration de la séquence de démarrage, du transfert initial du noyau au démarrage de tous les services nécessaires.

Cet article se veut un guide complet pour comprendre et résoudre les échecs de démarrage courants liés à systemd. Nous explorerons des méthodes pratiques pour analyser les journaux de démarrage, identifier les services problématiques et dépanner les conflits complexes d'ordre d'unité. À la fin de ce guide, vous disposerez d'une approche systématique pour diagnostiquer et corriger les problèmes de démarrage, garantissant que vos systèmes Linux retrouvent un état sain en toute confiance.

Comprendre le processus de démarrage Systemd

Systemd gère le processus de démarrage Linux via un système d'« unités ». Ces unités décrivent diverses ressources et services système, tels que les services (.service), les points de montage (.mount), les périphériques (.device) et les cibles (.target). Les cibles sont des unités spéciales qui regroupent d'autres unités et représentent des points de synchronisation ou des états spécifiques pendant le processus de démarrage, comme multi-user.target (le niveau d'exécution traditionnel 3) ou graphical.target (niveau d'exécution 5).

Le processus de démarrage implique généralement :
1. Initialisation du noyau : Le noyau se charge et initialise le matériel.
2. Étape Initramfs : Un système de fichiers RAM initial (initramfs) est chargé, qui inclut les pilotes et outils essentiels pour monter le système de fichiers racine.
3. Démarrage Systemd : Systemd prend le relais en tant que PID 1, démarrant le default.target (qui pointe souvent vers multi-user.target ou graphical.target).
4. Activation des unités : Systemd lit les fichiers d'unité, résout les dépendances et démarre les services et les montages de manière hautement parallèle.

Les problèmes de démarrage peuvent survenir à n'importe laquelle de ces étapes, mais ce guide se concentre principalement sur les problèmes qui se manifestent une fois que systemd a démarré.

Premier triage : Accéder aux journaux de démarrage

Lorsque votre système ne démarre pas correctement, la première étape et la plus critique est d'accéder aux journaux de démarrage. Ces journaux fournissent des indices sur ce qui n'a pas fonctionné. Si votre système ne démarre pas dans un environnement graphique ou même un TTY standard, vous devrez utiliser des méthodes alternatives.

1. Utilisation de `journalctl` (Depuis le mode Secours/Urgence ou un média Live)

journalctl est l'utilitaire permettant d'interroger le journal systemd. Si votre système peut démarrer en mode secours ou mode urgence, ou si vous utilisez une clé USB/CD live pour accéder à votre disque, journalctl est votre outil principal.

Pour afficher les journaux du démarrage précédent :

journalctl -b -1

Pour afficher tous les messages depuis le démarrage du système :

journalctl -b

Pour afficher les journaux relatifs aux unités en échec :

journalctl -b -p err..emerg # Afficher les messages d'erreur, critiques, d'alerte, d'urgence
journalctl -b --since "-5min" # Afficher les journaux des 5 dernières minutes du démarrage actuel

Si vous utilisez un environnement live, vous devrez d'abord chrooter dans la partition racine de votre système pour accéder à ses fichiers de journal.

2. Utilisation de `dmesg`

dmesg affiche le tampon circulaire du noyau, qui contient les messages du noyau pendant le démarrage. C'est particulièrement utile pour les problèmes survenant très tôt dans le processus de démarrage, avant que systemd ne prenne entièrement le relais.

dmesg

3. Examen du statut des unités

Une fois dans un shell utilisable (mode secours, mode urgence, ou environnement live avec chroot), vous pouvez vérifier l'état de toutes les unités systemd.

systemctl --failed

Cette commande liste toutes les unités qui n'ont pas réussi à démarrer. Pour des informations détaillées sur une unité en échec spécifique, utilisez :

systemctl status <nom_unite>.service

Et pour afficher ses entrées de journal spécifiques :

journalctl -u <nom_unite>.service -b

Problèmes et solutions courants de démarrage Systemd

1. Services échoués et défaillances d'unité

Problème : Un service critique ne démarre pas, empêchant le système d'atteindre la cible désirée (par exemple, multi-user.target). Cela se manifeste souvent par le passage du système en mode urgence.

Symptômes : systemctl --failed affiche une ou plusieurs unités avec l'état « failed » (échec). journalctl -u <nom_unite>.service révèle des messages d'erreur indiquant pourquoi le service n'a pas pu démarrer.

Causes courantes :
* Configuration incorrecte : Faute de frappe dans un fichier de configuration, chemins incorrects, dépendances manquantes.
* Fichiers/Dépendances manquants : Un service tente d'accéder à un fichier ou un répertoire qui n'existe pas ou est inaccessible.
* Épuisement des ressources : Le service essaie d'allouer trop de mémoire ou d'autres ressources.
* Problèmes de permissions : Le service n'a pas les permissions nécessaires pour lire/écrire des fichiers ou exécuter des commandes.

Solutions :
1. Identifier l'unité en échec : Utilisez systemctl --failed.
2. Inspecter les journaux : Exécutez journalctl -u <nom_unite>.service -b pour des messages d'erreur détaillés.
3. Corriger la configuration : Modifiez le fichier de configuration du service (par exemple, /etc/systemd/system/<nom_unite>.service ou les fichiers dans /etc/). Faites attention aux directives ExecStart, WorkingDirectory, User, Group, Environment.
4. Vérifier les dépendances : Assurez-vous que toutes les directives Wants=, Requires=, After=, Before= sont correctement spécifiées et que les services requis sont activés.
5. Redémarrer et réactiver : Après avoir effectué les modifications, exécutez systemctl daemon-reload, puis essayez systemctl start <nom_unite>.service et systemctl enable <nom_unite>.service.

Exemple : Un service web personnalisé mywebapp.service échoue car sa base de données n'est pas disponible.

# Vérifier le statut
systemctl status mywebapp.service

# Vérifier les journaux pour des indices
journalctl -u mywebapp.service -b

# Modifier le fichier d'unité (par exemple, dans /etc/systemd/system/mywebapp.service)
# Ajouter/modifier la directive After= pour s'assurer que la base de données démarre en premier
# ex : After=postgresql.service mysql.service

# Recharger systemd et réessayer
systemctl daemon-reload
systemctl start mywebapp.service
systemctl enable mywebapp.service # S'assurer qu'il démarre au prochain démarrage

2. Problèmes de système de fichiers

Problème : Des systèmes de fichiers corrompus ou des entrées incorrectes dans /etc/fstab peuvent empêcher le système de monter des partitions critiques, menant au mode urgence.

Symptômes : Messages d'erreur concernant des échecs de fsck, des erreurs de mount, ou le système passant en emergency mode avec un message comme « Give root password for maintenance (or type Control-D to continue) ».

Causes courantes :
* Système de fichiers « sale » : Arrêt incorrect, perte de courant.
* /etc/fstab incorrect : Faute de frappe dans l'UUID/chemin du périphérique, type de système de fichiers erroné, noauto manquant pour les montages non critiques.
* Défaillance matérielle : Corruption du disque.

Solutions :
1. Accéder au mode urgence : Si vous y êtes invité, entrez le mot de passe root.
2. Vérifier /etc/fstab : Examinez attentivement /etc/fstab pour toute erreur. Commentez les lignes suspectes avec # temporairement.
3. Exécuter fsck : Vérifiez et réparez manuellement les systèmes de fichiers. Par exemple, si /dev/sda1 est la partition racine :
bash # Démonter si possible (pour les partitions non-racine), ou redémarrer avec le paramètre fsck umount /dev/sda1 fsck -y /dev/sda1
Conseil : Si vous ne pouvez pas démonter la partition racine, vous devrez peut-être démarrer à partir d'une clé USB live et exécuter fsck de là.
4. Redémarrer : Après avoir effectué les modifications ou exécuté fsck, essayez de redémarrer.

3. Conflits de dépendances et ordre des unités

Problème : Les services démarrent dans le mauvais ordre, ou les unités ont des dépendances conflictuelles, entraînant des blocages ou des échecs.

Symptômes : Services qui expirent, services échouant car leurs dépendances ne sont pas prêtes, systemd-analyze plot affichant de longues chaînes ou des cycles.

Causes courantes :
* Directives Wants=, Requires=, After=, Before= mal configurées dans les fichiers d'unité.
* Unités attendant des ressources qui ne sont pas encore disponibles.

Solutions :
1. Analyser la séquence de démarrage : Utilisez systemd-analyze pour visualiser le processus de démarrage.
* systemd-analyze blame : Affiche les services classés par leur temps de démarrage, mettant en évidence les unités lentes.
* systemd-analyze critical-chain : Affiche le chemin critique des unités qui ont un impact direct sur le temps de démarrage global.
* systemd-analyze plot > boot.svg : Génère une image SVG du graphique complet des dépendances de démarrage, inestimable pour les problèmes complexes.

Inspecter les dépendances d'unité : Utilisez systemctl list-dependencies <nom_unite> pour voir ce qu'une unité requiert et ce qui en dépend.
Ajuster les directives du fichier d'unité :
- After=, Before= : Contrôlent l'ordre des unités. Si A.service a After=B.service, A démarrera après B (si B est démarré). Utilisez After= pour la plupart des besoins d'ordonnancement.
- Wants= : Exprime une dépendance faible. Si A.service Wants=B.service, B sera démarré lorsque A démarrera, mais A continuera même si B échoue.
- Requires= : Exprime une dépendance forte. Si A.service Requires=B.service, B sera démarré lorsque A démarrera, et si B échoue ou est arrêté, A sera également arrêté.
- Conflicts= : Garantit qu'une unité spécifique est arrêtée si l'unité actuelle est démarrée, et vice-versa.
- PartOf= : Lie le cycle de vie d'une unité à une autre (par exemple, si une slice est arrêtée, toutes les unités PartOf elle sont également arrêtées).
Conseil : Préférez toujours After= et Wants= pour la plupart des dépendances afin d'éviter de créer un couplage trop fort qui pourrait entraîner des blocages ou des cascades d'échecs.

4. Paniques du noyau / Problèmes Initramfs

Problème : Le système échoue à démarrer très tôt, souvent avant que systemd ne prenne entièrement le relais, affichant des messages comme « Kernel panic - not syncing » ou liés à dracut ou initramfs.

Symptômes : Échec de démarrage précoce, souvent avec un mur de texte affichant des traces de pile ou des messages concernant un périphérique racine manquant, /dev/root introuvable, etc.

Causes courantes :
* Modules du noyau manquants : L'Initramfs ne contient pas les pilotes nécessaires pour le système de fichiers racine (par exemple, LVM, RAID, contrôleurs de disque spécifiques).
* Noyau/Initramfs corrompu : Les fichiers sont endommagés.
* Paramètres du noyau incorrects : Le paramètre root= dans GRUB pointe vers le mauvais périphérique.

Solutions :
1. Reconstruire l'Initramfs : C'est une solution courante. Démarrez dans un environnement live ou avec un autre noyau, chrootez dans votre système et reconstruisez l'initramfs.
```bash
# Exemple pour Dracut (Fedora/RHEL/CentOS)
dracut -f -v /boot/initramfs-$(uname -r).img $(uname -r)

# Exemple pour mkinitcpio (Arch Linux)

mkinitcpio -P

# Exemple pour update-initramfs (Debian/Ubuntu)
update-initramfs -u -k all
```

Vérifier la configuration de GRUB : Vérifiez /boot/grub/grub.cfg (ou /etc/default/grub si vous le régénérez) pour le bon paramètre root= et le chemin initrd.
Paramètres du noyau : Si vous soupçonnez qu'un module spécifique est manquant ou cause des problèmes, vous pouvez essayer d'ajouter des paramètres de noyau dans GRUB (par exemple, rd.break pour tomber dans le shell initramfs pour le débogage).

5. Problèmes de GRUB/Chargeur de démarrage

Problème : Le système n'atteint même pas le point où le noyau se charge, ou il reste bloqué au menu GRUB.

Symptômes : « No boot device found », invite de commande GRUB rescue, ou GRUB ne parvient pas à charger le noyau.

Causes courantes :
* Chargeur de démarrage corrompu.
* Configuration GRUB incorrecte pointant vers un noyau/initramfs inexistant.
* Paramètres BIOS/UEFI empêchant un ordre de démarrage correct.

Solutions :
1. Réinstaller GRUB : Démarrez à partir d'une clé USB live, chrootez dans votre système et réinstallez GRUB sur la partition MBR/EFI.
```bash
# Exemple
mount /dev/sdaX /mnt # Monter la partition racine

mount /dev/sdaY /mnt/boot/efi # Si partition EFI séparée

for i in /dev /dev/pts /proc /sys /run; do mount --bind $i /mnt$i; done
chroot /mnt

grub-install /dev/sda # Installer sur le disque principal

grub-mkconfig -o /boot/grub/grub.cfg # Régénérer la configuration GRUB

exit
umount -R /mnt
reboot
```

Vérifier les paramètres BIOS/UEFI : Assurez-vous que le bon lecteur de démarrage est prioritaire.

Techniques de dépannage avancées

Démarrer en mode secours/urgence

Ces modes fournissent un environnement minimal pour le dépannage. Pour y accéder :

Pendant GRUB : Appuyez sur e pour modifier la ligne de commande du noyau.
Localiser la ligne linux : Trouvez la ligne commençant par linux (ou linuxefi).
Ajouter systemd.unit=rescue.target pour le mode secours (la plupart des services sont désactivés, shell mono-utilisateur).
Ajouter systemd.unit=emergency.target pour le mode urgence (services minimaux, souvent racine en lecture seule).
Appuyez sur Ctrl+X ou F10 pour démarrer.

Utilisation de `rd.break` pour le débogage Initramfs

Ajouter rd.break à la ligne de commande du noyau dans GRUB vous fera tomber dans un shell au sein de l'initramfs avant que le système de fichiers racine réel ne soit monté. C'est extrêmement utile pour le débogage des problèmes d'initramfs, tels que les pilotes manquants ou les problèmes de configuration LVM/RAID.

Une fois dans le shell initramfs, vous pouvez :
* Inspecter lsblk, mount.
* Vérifier les fichiers manquants dans /sysroot.
* Essayer de monter manuellement le système de fichiers racine.

Analyse des performances de démarrage

Bien que ce ne soit pas strictement une « défaillance », des temps de démarrage lents peuvent indiquer des problèmes sous-jacents ou des configurations de services inefficaces.

systemd-analyze blame : Identifiez les services qui prennent le plus de temps à démarrer.
systemd-analyze critical-chain : Comprenez le chemin critique des dépendances ayant un impact sur le temps de démarrage global.

Utilisez ces outils pour identifier les goulots d'étranglement et optimiser le démarrage des unités en ajustant les directives After=, Requires=, TimeoutStartSec= ou Type=.

Prévention et bonnes pratiques

Tester les changements : Avant de déployer des modifications de fichiers d'unité en production, testez-les dans un environnement de staging.
Sauvegarder la configuration : Sauvegardez régulièrement /etc/ ou au moins les fichiers critiques de /etc/systemd/system/.
Comprendre les directives d'unité : Une solide compréhension des pages de manuel systemd.service(5) et systemd.unit(5) est inestimable.
Utiliser les fichiers de configuration additionnels (Drop-in Files) : Au lieu de modifier directement les fichiers d'unité de /lib/systemd/system/ (qui peuvent être écrasés par les mises à jour), utilisez des fichiers de configuration additionnels (/etc/systemd/system/<nom_unite>.service.d/*.conf) pour les configurations personnalisées.
Conserver les noyaux : Gardez toujours au moins un ancien noyau connu et fonctionnel sur votre système pour démarrer si un nouveau noyau cause des problèmes.

Conclusion

La résolution des problèmes de démarrage systemd exige une approche systématique, en commençant par une analyse efficace des journaux. En comprenant l'architecture basée sur les unités de systemd et en exploitant des outils comme journalctl, systemctl et systemd-analyze, vous pouvez identifier efficacement la cause première des échecs de démarrage, qu'il s'agisse d'un service mal configuré, d'un problème de système de fichiers ou d'un conflit de dépendances complexe. La capacité à démarrer en mode secours ou d'urgence, associée à des techniques de débogage avancées, vous permet de reprendre le contrôle de votre système même lorsqu'il semble complètement insensible. Avec ces stratégies et bonnes pratiques, vous serez bien équipé pour relever la plupart des défis de démarrage systemd et maintenir des opérations Linux stables et fiables.