## Introduction Systemd est le gestionnaire de démarrage et de services par défaut sur la plupart des distributions Linux modernes, notamment Ubuntu, Debian, Fedora, CentOS/RHEL et Arch. En tant qu'opérateur, développeur ou consultant DevOps, vous devrez fréquemment démarrer, arrêter, activer, inspecter et résoudre les problèmes des services. Ce guide couvre les commandes systemd essentielles avec des exemples pratiques, axés sur des scénarios réels. Vous apprendrez à vérifier la version de systemd, à gérer les services avec systemctl, à consulter les journaux avec journalctl, à modifier les fichiers d'unité en toute sécurité et à récupérer après des échecs courants. Chaque section inclut des commandes avec la sortie attendue et des étapes de vérification. Nous mettons l'accent sur la sécurité opérationnelle : observer avant de modifier, limiter la zone d'impact, utiliser des variables d'environnement à la place de secrets réels, vérifier les résultats et documenter les procédures de récupération. À la fin, vous disposerez d'une boîte à outils en ligne de commande solide pour les opérations systemd quotidiennes. ## Inventaire de la version et de l'environnement Avant d'exécuter toute commande systemd, confirmez l'environnement. Vérifiez la version de systemd, la version du système d'exploitation et la version du noyau. Cela garantit l'utilisation de la syntaxe et des fonctionnalités correctes. Vérifier la version de systemd : systemctl --version Sortie attendue (exemple) : systemd 252 (252.5-1ubuntu3) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE -TPM2 -BZIP2 -LZ4 -XZ -ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified Vérifier la version du système d'exploitation : cat /etc/os-release Extrait de sortie attendue : NAME="Ubuntu" VERSION="22.04.3 LTS (Jammy Jellyfish)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 22.04.3 LTS" Vérifier la version du noyau : uname -r Sortie attendue : 5.15.0-91-generic Observation en lecture seule : Utilisez systemctl status (sans sudo) pour afficher l'état d'un service spécifique, par exemple, ssh : systemctl status ssh Sortie attendue (tronquée) : ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2024-01-01 12:00:00 UTC; 2h 30min ago Docs: man:sshd(8) man:sshd_config(5) Main PID: 1234 (sshd) Tasks: 1 (limit: 4915) Memory: 1.2M CPU: 123ms CGroup: /system.slice/ssh.service └─1234 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups" Si le service ne fonctionne pas, la ligne Active affichera inactive (dead) ou failed . Notez le nom exact du service, car il est sensible à la casse et peut varier selon les distributions. Prérequis : La plupart des commandes de gestion ( start , stop , restart , enable , disable ) nécessitent les privilèges root. Utilisez sudo ou exécutez en tant que root. Vérifiez toujours que votre utilisateur dispose des autorisations nécessaires avec sudo -l . ## Chemin de configuration sûr Modifier directement les fichiers d'unité systemd peut être risqué. Utilisez les outils et méthodes appropriés pour éviter de casser les services. ### Afficher les fichiers d'unité Lister tous les fichiers d'unité : systemctl list-unit-files --type=service Sortie attendue (premières lignes) : UNIT FILE STATE VENDOR PRESET accounts-daemon.service enabled enabled acpid.service disabled enabled also-restore.service static enabled ... Afficher le contenu d'un fichier d'unité : systemctl cat ssh.service Sortie attendue : # /lib/systemd/system/ssh.service [Unit] Description=OpenBSD Secure Shell server Documentation=man:sshd(8) man:sshd_config(5) After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run [Service] EnvironmentFile=-/etc/default/ssh ExecStartPre=/usr/sbin/sshd -t ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/usr/sbin/sshd -t ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartPreventExitStatus=255 Type=notify RuntimeDirectory=sshd RuntimeDirectoryMode=0755 [Install] WantedBy=multi-user.target Alias=sshd.service ### Créer des fichiers de remplacement Ne modifiez jamais directement les fichiers dans /lib/systemd/system/ ou /usr/lib/systemd/system/ , car les mises à jour des paquets peuvent les écraser. Créez plutôt des fichiers de remplacement (drop-in). Créer un répertoire de remplacement et modifier le fichier de remplacement : sudo systemctl edit ssh.service Cela ouvre un éditeur de texte (généralement nano ou vim) pour un nouveau fichier situé dans /etc/systemd/system/ssh.service.d/override.conf . Ajoutez des directives sous la section appropriée, par exemple, pour changer la politique de redémarrage : [Service] Restart=always RestartSec=5s Enregistrez et quittez. Rechargez ensuite la configuration du gestionnaire systemd et redémarrez le service : sudo systemctl daemon-reload sudo systemctl restart ssh.service Vérifiez que le remplacement a pris effet : systemctl cat ssh.service Vous devriez voir des lignes supplémentaires indiquant le fichier de remplacement. Vérifier les erreurs de syntaxe avant d'appliquer : sudo systemd-analyze verify ssh.service En cas d'erreurs, il les signalera ; sinon, aucune sortie n'indique le succès. Zone d'impact : Seul le service concerné est modifié. Utilisez systemctl status ssh.service pour confirmer qu'il fonctionne après le changement. Si le service ne démarre pas, annulez le remplacement en supprimant le fichier et en exécutant sudo systemctl daemon-reload et sudo systemctl restart ssh.service . Procédure de récupération : Conservez toujours une copie du fichier d'unité original ou sachez comment le régénérer. Pour les remplacements, la simple suppression du fichier de remplacement restaure le comportement par défaut. ## Vérification et diagnostics La vérification garantit que les services fonctionnent correctement. Utilisez une combinaison d'état, de journaux et de vérifications de dépendances. ### État et santé du service Vérifier si un service est actif (en cours d'exécution) et activé au démarrage : systemctl is-active ssh.service systemctl is-enabled ssh.service Sortie attendue : active et enabled , respectivement. Sinon, les commandes renvoient inactive ou failed , et disabled ou static , avec un code de sortie non nul. Afficher l'état détaillé, y compris les dernières lignes de journal : systemctl status ssh.service --no-pager -l Cela montre les dernières entrées de journal du service, ce qui peut être précieux pour diagnostiquer les problèmes. ### Analyser les problèmes de démarrage et de dépendances Afficher la chronologie du processus de démarrage pour identifier les services lents : systemd-analyze blame Sortie attendue (exemple) : 5.123s NetworkManager-wait-online.service 2.456s apt-daily.service 1.789s docker.service ... Afficher la chaîne critique pour une cible spécifique : systemd-analyze critical-chain multi-user.target Cela aide à comprendre quels services bloquent le processus de démarrage. Lister les dépendances d'un service : systemctl list-dependencies ssh.service Sortie attendue : ssh.service ● ├─system.slice ● ├─sshd-keygen.service ● └─network.target ● └─network-pre.target Cela montre ce que ssh.service requiert et ce qui en dépend. ### Inspection du journal Le journal est le journal central de systemd. Utilisez journalctl pour interroger les journaux. Afficher les journaux d'un service spécifique depuis le dernier démarrage : journalctl -u ssh.service -b Suivre les journaux en temps réel : journalctl -u ssh.service -f Filtrer par priorité (par exemple, erreurs et plus graves) : journalctl -u ssh.service -p err Limiter la sortie à une plage de temps : journalctl -u ssh.service --since "2024-01-01 10:00:00" --until "2024-01-01 12:00:00" Vérifier l'utilisation du disque par le journal : journalctl --disk-usage Sortie attendue : Archived and active journals take up 152.0M in the file system. Si le journal est trop volumineux, configurez des limites dans /etc/systemd/journald.conf (par exemple, SystemMaxUse=500M ) et redémarrez systemd-journald . ## Modes de défaillance et récupération Les services échouent pour diverses raisons : erreurs de configuration, dépendances manquantes, limites de ressources ou plantages. Savoir identifier et récupérer est crucial. ### États de défaillance courants - inactive (dead) : Le service n'est pas en cours d'exécution et n'est pas prévu pour s'exécuter. - failed : Le service a tenté de démarrer mais a planté ou s'est terminé avec une erreur. - activating : Le service est en cours de démarrage. - deactivating : Le service est en cours d'arrêt. - auto-restart : Le service sera redémarré automatiquement par systemd. Vérifier les unités en échec sur l'ensemble du système : systemctl --failed Sortie attendue (le cas échéant) : UNIT LOAD ACTIVE SUB DESCRIPTION ● myapp.service loaded failed failed My Custom Application En cas d'échec, examinez avec systemctl status myapp.service et journalctl -u myapp.service -b -e (le -e saute à la fin du journal). ### Déboguer un service en échec Supposons qu'un service myapp.service échoue. Effectuez les opérations suivantes : - Vérifier l'état : systemctl status myapp.service Recherchez la ligne Active et les messages d'erreur. - Afficher les journaux récents : journalctl -u myapp.service -n 50 --no-pager Cela montre les 50 dernières lignes de journal. - Examiner le fichier d'unité : systemctl cat myapp.service Vérifiez le chemin ExecStart et la syntaxe de la commande. - Exécuter manuellement la commande ExecStart (si sûr) pour voir les erreurs directement. - Vérifier les autorisations de fichiers et les chemins. Assurez-vous que l'exécutable et les fichiers de configuration sont accessibles à l'utilisateur spécifié dans l'unité (directive User= ). - Utiliser systemd-analyze verify pour vérifier la syntaxe du fichier d'unité : sudo systemd-analyze verify myapp.service ### Actions de récupération Redémarrer un service en échec : sudo systemctl restart myapp.service Si le service a un problème de dépendance, redémarrez également les dépendances : sudo systemctl restart myapp.service --no-block Réinitialiser l'état d'échec : sudo systemctl reset-failed myapp.service Désactiver temporairement un service : sudo systemctl stop myapp.service sudo systemctl disable myapp.service Masquer un service pour empêcher son démarrage : sudo systemctl mask myapp.service Pour démasquer : sudo systemctl unmask myapp.service Annuler un remplacement : Si un remplacement récent a causé l'échec, supprimez le fichier de remplacement : sudo rm /etc/systemd/system/myapp.service.d/override.conf sudo systemctl daemon-reload sudo systemctl restart myapp.service ### Récupérer après des échecs de démarrage Si le système ne démarre pas en raison d'un mauvais service, utilisez le mode de récupération ou un CD live. Ajoutez systemd.unit=rescue.target ou systemd.unit=emergency.target à la ligne de commande du noyau pour démarrer dans un environnement minimal. Désactivez ou corrigez ensuite le service fautif. ## Liste de contrôle des opérations Utilisez cette liste de contrôle pour gérer en toute sécurité les services systemd en production. ### Avant tout changement - [ ] Confirmez le nom exact du service : systemctl list-units --type=service | grep - [ ] Enregistrez l'état actuel : systemctl status --no-pager > /tmp/service_status_before.txt - [ ] Vérifiez les dépendances : systemctl list-dependencies - [ ] Assurez-vous d'avoir un plan de restauration (par exemple, sauvegarde des fichiers d'unité de remplacement ou état original documenté). - [ ] Informez les utilisateurs ou l'équipe concernés si le service est critique. ### Pendant le changement - [ ] Utilisez sudo systemctl plutôt que de modifier directement les fichiers lorsque c'est possible. - [ ] Pour les modifications de fichiers d'unité, utilisez sudo systemctl edit pour créer des remplacements. - [ ] Après modification, exécutez sudo systemd-analyze verify pour détecter les erreurs de syntaxe. - [ ] Rechargez le démon si les fichiers d'unité ont changé : sudo systemctl daemon-reload . - [ ] Appliquez le changement : sudo systemctl restart ou sudo systemctl reload si pris en charge. ### Après le changement - [ ] Vérifiez que le service est actif et en cours d'exécution : systemctl is-active doit renvoyer active . - [ ] Vérifiez les erreurs dans les journaux : journalctl -u -n 20 --no-pager . - [ ] Confirmez que le service est activé s'il doit démarrer au démarrage : systemctl is-enabled . - [ ] Surveillez pendant quelques minutes pour vous assurer qu'il n'y a pas de redémarrages inattendus : systemctl status affiche la durée de fonctionnement. - [ ] Enregistrez le changement et toute nouvelle observation pour référence future. Exemple : Redémarrer Nginx # Avant systemctl status nginx --no-pager | tee /tmp/nginx_status_before.txt # Pendant sudo systemctl restart nginx # Après systemctl is-active nginx # attendu : active journalctl -u nginx -n 20 --no-pager ## Conclusion Maîtriser les commandes de base de systemd est essentiel pour quiconque gère des systèmes Linux. Ce guide a couvert l'inventaire, la configuration sûre, la vérification, la récupération après échec et une liste de contrôle des opérations. En suivant les principes d'observation, d'intervention minimale et de vérification, vous pouvez exploiter les services gérés par systemd en toute confiance. Comme prochaine étape, entraînez-vous avec ces commandes sur un système de test. Créez un service simple, apportez des modifications à l'aide de remplacements, provoquez des échecs et récupérez. Plus vous serez familier avec systemctl, journalctl et systemd-analyze, plus vite vous pourrez diagnostiquer et résoudre les problèmes en production. N'oubliez pas de toujours avoir un plan de restauration et de documenter vos actions.