Résolution des Problèmes de Démarrage Systemd : Problèmes Courants et Solutions

Les problèmes de démarrage Linux semblent urgents car vous perdez souvent les outils confortables en premier. SSH peut être indisponible, la connexion graphique peut ne jamais apparaître, et la console peut vous déposer en mode d'urgence avec un message qui semble pire qu'il ne l'est. Avec les problèmes de démarrage systemd, la meilleure première action n'est pas de deviner. Trouvez le point où le démarrage s'est arrêté, puis travaillez en arrière à travers les journaux d'unités, les échecs de montage, les erreurs de dépendance ou les messages précoces du noyau.

Ce guide se concentre sur les échecs qui surviennent une fois que le noyau a démarré systemd en tant que PID 1, ainsi que quelques problèmes voisins qui ressemblent à des échecs systemd depuis la console : mauvaises entrées /etc/fstab, problèmes d'initramfs et erreurs de chargeur d'amorçage.

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 runlevel 3 traditionnel) ou graphical.target (runlevel 5).

Le processus de démarrage implique généralement :

1. Initialisation du Noyau : Le noyau charge et initialise le matériel.
2. Étape Initramfs : Un système de fichiers RAM initial est chargé, qui inclut les pilotes et outils essentiels pour monter le système de fichiers racine.
3. Démarrage de Systemd : Systemd prend le relais en tant que PID 1, démarrant le default.target (qui souvent crée un lien symbolique vers multi-user.target ou graphical.target).
4. Activation des Unités : Systemd lit les fichiers d'unités, 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é.

Triage Initial : Accès aux Journaux de Démarrage

Lorsque votre système ne parvient pas à démarrer correctement, la première et la plus critique des étapes est d'accéder aux journaux de démarrage. Ces journaux fournissent des indices sur ce qui a mal tourné. 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 de Secours/D'urgence ou un Support Live)

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

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

journalctl -b -1

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

journalctl -b

Pour voir les journaux liés aux unités défaillantes :

journalctl -b -p err..emerg # Affiche les erreurs, critiques, alertes, messages d'urgence
journalctl -b --since "-5min" # Affiche les journaux des 5 dernières minutes du démarrage en cours

Si vous utilisez un environnement live, vous n'avez pas toujours besoin d'un chroot complet juste pour lire les journaux. Montez le système installé et pointez journalctl vers celui-ci :

mount /dev/mapper/vg0-root /mnt
journalctl --directory=/mnt/var/log/journal -b -1

Sur les systèmes sans journaux persistants, les anciens journaux de démarrage peuvent ne pas exister sous /var/log/journal. Dans ce cas, vérifiez les journaux spécifiques à la distribution sous /var/log, ou reproduisez le démarrage après avoir activé la journalisation persistante lorsque le système est suffisamment sain pour le faire.

2. Utilisation de dmesg

dmesg affiche le tampon circulaire du noyau, qui contient les messages du noyau pendant le démarrage. Ceci est particulièrement utile pour les problèmes survenant très tôt dans le processus de démarrage, avant que systemd n'ait complètement pris le relais.

dmesg

3. Examen de l'État des Unités

Une fois dans un shell utilisable (mode de secours, mode d'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 ont échoué à démarrer. Pour des informations détaillées sur une unité défaillante spécifique, utilisez :

systemctl status <nom_unite>.service

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

journalctl -u <nom_unite>.service -b

Problèmes Courants de Démarrage Systemd et Solutions

1. Services Défaillants et Échecs d'Unités

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

Symptômes : systemctl --failed montre une ou plusieurs unités avec un état "failed". 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 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é Défaillante : 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é des 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 l'état
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
# par exemple, 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, conduisant au mode d'urgence.

Symptômes : Messages d'erreur concernant des échecs de fsck, des erreurs de mount, ou le système tombant en mode d'urgence 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/le chemin du périphérique, mauvais type de système de fichiers, noauto manquant pour les montages non critiques.
• Défaillance Matérielle : Corruption du disque.

Solutions :

1. Accéder au Mode d'Urgence : Si invité, entrez le mot de passe root.
2. Vérifier /etc/fstab : Examinez attentivement /etc/fstab pour toute erreur. Commentez temporairement les lignes suspectes avec #.
3. Exécuter fsck avec précaution : Vérifiez et réparez manuellement les systèmes de fichiers uniquement lorsqu'ils sont démontés, ou montés en lecture seule dans un contexte de maintenance où votre distribution le documente comme sûr. Pour une partition non racine :

   umount /dev/sdb1
   fsck -f /dev/sdb1
   

   Si le système de fichiers racine nécessite une réparation, démarrez à partir d'un support live ou d'un environnement de secours et exécutez fsck à partir de là. Évitez fsck -y comme premier geste sur des disques importants ; examinez les invites sauf si vous avez déjà une sauvegarde ou si vous comprenez les dommages.
4. Redémarrer : Après avoir effectué des modifications ou exécuté fsck, essayez de redémarrer.

3. Conflits de Dépendance et Ordonnancement des Unités

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

Symptômes : Services expirant, services échouant parce que leurs dépendances ne sont pas prêtes, systemd-analyze plot montrant de longues chaînes ou des cycles.

Causes Courantes :

• Directives Wants=, Requires=, After=, Before= mal configurées dans les fichiers d'unités.
• 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 impactent directement le temps de démarrage global.
   • systemd-analyze plot > boot.svg : Génère une image SVG du graphe de dépendances de démarrage complet, inestimable pour les problèmes complexes.

2. Inspecter les Dépendances des Unités : Utilisez systemctl list-dependencies <nom_unite> pour voir ce qu'une unité requiert et ce qui en dépend.

3. Ajuster les Directives du Fichier d'Unité :

   • After=, Before= : Contrôlent l'ordonnancement des unités. Si A.service a After=B.service, A démarrera après B (si B est démarré du tout). 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émarre, mais A continuera même si B échoue.
   • Requires= : Exprime une dépendance forte. Si A.service Requires=B.service, B est attiré lorsque A démarre, et A échoue si B ne peut pas être démarré. Si B est explicitement arrêté, A est également arrêté.
   • Conflicts= : Garantit qu'une unité spécifique est arrêtée si l'unité courante 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 sont également arrêtées).

   Astuce : Préférez toujours After= et Wants= pour la plupart des dépendances afin d'éviter de créer un couplage fort qui pourrait conduire à des blocages ou des cascades d'échecs.

4. Paniques du Noyau / Problèmes d'Initramfs

Problème : Le système échoue à démarrer très tôt, souvent avant que systemd ne prenne complètement 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 montrant des traces de pile ou des messages concernant un périphérique racine manquant, /dev/root introuvable, etc.

Causes Courantes :

• Modules du Noyau Manquants : 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 Initramfs : C'est une correction courante. Démarrez dans un environnement live ou un autre noyau, chroot dans votre système, et reconstruisez l'initramfs.

   # 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
   

2. Vérifier la Configuration GRUB : Vérifiez /boot/grub/grub.cfg (ou /etc/default/grub si vous le régénérez) pour le paramètre root= correct et le chemin initrd.
3. 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 du noyau dans GRUB (par exemple, rd.break pour tomber dans le shell initramfs pour le débogage).

5. Problèmes de GRUB/Chargeur d'Amorçage

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 secours GRUB, ou GRUB ne parvient pas à charger le noyau.

Causes Courantes :

• Chargeur d'amorçage 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, chroot dans votre système, et réinstallez GRUB sur le MBR/la partition EFI.

   # 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
   

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

Techniques Avancées de Dépannage

Démarrer en Mode de Secours/D'urgence

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

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

Utilisation de rd.break pour le Débogage d'Initramfs

Ajouter rd.break à la ligne de commande du noyau dans GRUB vous déposera dans un shell à l'intérieur de l'initramfs avant que le système de fichiers racine réel ne soit monté. Ceci est extrêmement utile pour déboguer les 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.

Analyser les Performances de Démarrage

Bien que ce ne soit pas strictement un "échec", 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 mettent le plus de temps à démarrer.
• systemd-analyze critical-chain : Comprenez le chemin critique des dépendances impactant le temps de démarrage global.

Une Séquence de Récupération Sûre

Lorsque vous êtes à la console et que la machine est à moitié démarrée, gardez la séquence de récupération simple :

1. Capturez l'erreur exacte à l'écran si possible.
2. Exécutez systemctl --failed.
3. Lisez journalctl -b -p err..alert --no-pager.
4. Si une unité a échoué, lisez journalctl -u nom-unite -b.
5. Si un montage a échoué, inspectez /etc/fstab, vérifiez les UUID avec blkid, et commentez uniquement le montage non critique suspect.
6. Si le système de fichiers racine ou initramfs est impliqué, passez au support live ou au mode de secours avant d'effectuer des réparations invasives.
7. Après les modifications de fichiers d'unités, exécutez systemctl daemon-reload et redémarrez uniquement l'unité affectée lorsque c'est possible.

La plupart des problèmes de démarrage systemd ne sont pas résolus en changeant beaucoup de choses à la fois. Une mauvaise ligne de montage, un disque manquant, un service avec un ExecStart= cassé, ou une erreur d'ordonnancement laisse une piste assez directe. Suivez cette piste, effectuez une petite réparation, et redémarrez uniquement lorsque le shell actuel ne peut pas tester la correction.

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

Conclusion

Résoudre les problèmes de démarrage systemd nécessite une approche systématique, 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 racine 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épendance complexe. La capacité de démarrer en modes de secours ou d'urgence, couplée à des techniques avancées de débogage, 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.