Services et journaux systemd : diagnostiquer pas à pas
Pour diagnostiquer un service Linux avec systemd, listez les actifs avec systemctl list-units --type=service, puis lisez l’état précis d’un service avec systemctl status nom.service. Pour ses journaux, utilisez journalctl -u nom.service -n 50 (-p err pour ne garder que les erreurs). En cas d’échec, observez l’état failed et le Main PID ; un message « Unit … could not be found » signale une coquille dans le nom. sudo systemctl restart n’est légitime que sur un service d’exercice sans risque, jamais sur un service système.
Aucune modification de configuration systemd n’est demandée dans ce parcours, aucun sudo systemctl non documenté, aucun service système sensible redémarré ou désactivé, aucune édition d’unit file (/etc/systemd/system/, /usr/lib/systemd/system/). systemctl restart, enable, disable et mask sont documentés pour la culture, mais aucune de ces commandes n’est exécutée sur un service système dans les étapes qui suivent.
Qu’est-ce que systemd et pourquoi l’utiliser pour diagnostiquer ?
systemd est le gestionnaire de services et de démarrage de la plupart des distributions Linux grand public. Comprendre ce qu’il fait aide à lire la suite sans se perdre dans des détails qui dépassent ce parcours.
Repérez systemd comme gestionnaire de services (PID 1)
Quand votre machine démarre, le premier processus lancé est presque toujours /sbin/init. Sur une distribution GNU/Linux moderne, ce binaire est un lien vers /usr/lib/systemd/systemd, et son nom de code est « systemd ». Il porte le numéro de processus 1 (PID 1), ce qui lui donne un statut particulier : les autres services démarrent par son intermédiaire. Pour confirmer la version installée sur votre machine, entrez :
systemctl --version
La première ligne de sortie affiche systemd 255 (255.4-1ubuntu8.17) sur Ubuntu 24.04. Les lignes suivantes listent les modules compilés (+PAM, +AUDIT, +SELINUX, +APPARMOR, etc.) ; elles n’ont pas d’incidence sur le parcours de cette page. Sur d’autres distributions (Fedora, Debian stable, Arch), la version exacte peut varier ; le synopsis des commandes reste largement compatible à partir de systemd 245 environ. Si votre version est nettement plus ancienne, prévoyez quelques variations de libellés.
Identifiez les unités de type service
systemd manipule des « unités » (units) qui représentent des ressources qu’il gère. Il en existe onze types : .service (le sujet de cette page), .socket, .mount, .target, .timer, .path, .swap, .device, .automount, .scope, .slice — liste documentée par man 5 systemd.unit. Cette page se limite au type service, qui désigne un programme de longue durée lancé et surveillé par systemd. Les autres types ont leurs propres pages de référence.
Tenez la configuration avancée hors du parcours
Modifier un unit file dans /etc/systemd/system/ ou créer un drop-in dans /etc/systemd/system/mon.service.d/ exige une bonne compréhension des directives [Unit], [Service] et [Install], et un protocole de relecture précis. Cette page parle de lecture, pas d’écriture. Aucune commande de modification d’unit file n’est illustrée ici ; pour les usages avancés, la documentation officielle de systemd reste la référence.
Comment lister les services actifs ?
Lister est la première étape avant de diagnostiquer. Trois commandes couvrent les besoins courants : lister ce qui tourne en mémoire, lister ce qui est installé sur le disque, et borner la sortie à votre propre session.
Listez les services en mémoire avec systemctl list-units --type=service
systemctl list-units --type=service --no-pager --no-legend
La sortie affiche cinq colonnes : UNIT, LOAD, ACTIVE, SUB, DESCRIPTION. Chaque ligne représente un service connu de systemd. Beaucoup apparaissent en loaded active exited (le service a tourné puis s’est terminé, par exemple après avoir configuré un sous-système) ; d’autres restent en loaded active running (ils tournent en continu). Les options --no-pager et --no-legend retirent la pagination et l’en-tête récapitulatif ; elles rendent la sortie plus facile à copier dans une note.
Filtrez par état avec --state=running
Pour ne garder que les services qui tournent en ce moment :
systemctl list-units --type=service --state=running --no-pager --no-legend
La sortie ne contient plus que les services active (running). Sur une machine de bureau classique, on en compte quelques dizaines ; sur un serveur, parfois plus d’une centaine. Cette commande est utile pour isoler ce qui tourne sans trier manuellement.
Listez les unités installées avec systemctl list-unit-files --type=service
La commande list-units montre ce qui est en mémoire. La commande list-unit-files montre ce qui est installé sur le disque :
systemctl list-unit-files --type=service --no-pager --no-legend
La colonne STATE indique l’état de démarrage automatique : enabled (démarrage automatique au boot), disabled (pas de démarrage automatique), static (sans section [Install], ne peut pas être activé), masked (lié à /dev/null, ne démarre jamais). Un service enabled n’est pas forcément démarré en ce moment ; un service disabled peut avoir été démarré à la main.
Limitez la sortie à l’utilisateur courant
systemd gère aussi une instance par utilisateur, distincte de l’instance système. Pour voir ce qui tourne dans votre session :
systemctl --user list-units --type=service --no-pager --no-legend
Le nombre d’unités est plus faible : votre session a ses propres services (dbus.service côté utilisateur, par exemple), indépendants du système. Cette commande est en lecture seule, sans privilège.
Comment lire l’état d’un service précis ?
Une fois la liste connue, l’étape suivante est de se concentrer sur un service qui pose question. Cinq sous-commandes de systemctl couvrent ce besoin : status, is-active, is-enabled, show, cat.
Utilisez systemctl status nom.service
systemctl status cron.service --no-pager
La sortie commence par une ligne d’en-tête ● cron.service - Regular background program processing daemon, suivie de plusieurs lignes clés :
Loaded: loaded (/usr/lib/systemd/system/cron.service; enabled; preset: enabled)— chemin du fichier unit et état d’activation au boot ;Active: active (running) since …— état et sous-état en cours, plus date de démarrage ;Docs: man:cron(8)— référence de documentation ;Main PID: 1231530 (cron)— PID principal ;Tasks: 14 (limit: 57763)— nombre de tâches ;Memory: 648.2M— mémoire consommée ;CPU: 11h 33min 30.515s— temps CPU cumulé ;CGroup: /system.slice/cron.service— arborescence cgroup.
status fonctionne sans privilège pour la lecture seule : tant que vous ne demandez pas un redémarrage, l’utilisateur ordinaire accède à cette vue d’ensemble.
Vérifiez l’état condensé avec is-active et is-enabled
Pour un retour condensé utilisable dans un script :
systemctl is-active cron.service
systemctl is-enabled cron.service
is-active renvoie active, inactive, failed ou unknown, avec un code de retour qui reflète l’état : 0 pour active, 3 pour inactive, 1 pour failed. is-enabled renvoie enabled, disabled, masked ou static, code retour 0 quand la valeur est l’une des attendues, 1 sinon. Ces deux commandes sont les plus économiques pour tester un état dans une boucle.
Affichez les propriétés clés avec systemctl show
systemctl show cron.service --property=Id,Type,ActiveState,SubState,UnitFileState --no-pager
La sortie affiche chaque propriété sur sa propre ligne, format Clé=Valeur :
Type=simple— type de service (ici, processus principal sans étape de pré-lancement) ;Id=cron.service— nom complet ;ActiveState=active— état d’activation ;SubState=running— sous-état ;UnitFileState=enabled— état d’activation au boot.
show accepte --property=Clé1,Clé2,… pour filtrer les propriétés utiles. Sans filtre, la sortie est très longue (centaines de lignes par service). Le filtrage est l’usage normal.
Lisez le fichier unit avec systemctl cat sans l’éditer
systemctl cat cron.service --no-pager
La sortie affiche le contenu du fichier unit, suivi des drop-ins éventuels. Pour cron.service, on observe trois sections :
# /usr/lib/systemd/system/cron.service
[Unit]
Description=Regular background program processing daemon
Documentation=man:cron(8)
After=remote-fs.target nss-user-lookup.target
[Service]
EnvironmentFile=-/etc/default/cron
ExecStart=/usr/sbin/cron -f -P $EXTRA_OPTS
IgnoreSIGPIPE=false
KillMode=process
Restart=on-failure
SyslogFacility=cron
[Install]
WantedBy=multi-user.target
[Unit] décrit les métadonnées et les relations (After=, Wants=, Requires=). [Service] contient la commande à lancer (ExecStart), les options de redémarrage (Restart=on-failure), et le mode d’arrêt (KillMode=process). [Install] précise la cible de démarrage (WantedBy=multi-user.target pour le mode multi-utilisateur). Cette commande est en lecture seule ; elle ne propose pas d’éditer le fichier.
Tenez restart/enable/mask hors du parcours nominal
systemctl restart nom.service redémarre un service. systemctl enable nom.service active le démarrage automatique au boot. systemctl disable fait l’inverse. systemctl mask nom.service empêche tout démarrage — automatique ou manuel — en liant l’unité à /dev/null. Ces quatre sous-commandes sont mentionnées ici pour que vous les reconnaissiez. Aucune n’est exécutée dans le parcours sur un service système ; redémarrer cron, ssh, systemd-journald ou un autre service système sensible relève d’une décision d’administration documentée, pas d’un réflexe de dépannage.
Comment lire les journaux d’un service ?
Une commande complète le diagnostic : journalctl. Elle lit le journal écrit par systemd-journald, avec des filtres utiles pour cibler une unité précise.
Filtrez par unité avec journalctl -u nom.service
journalctl -u cron.service -n 5 --no-pager -q
L’option -u filtre les entrées du journal pour une unité donnée. -n 5 borne la sortie aux cinq dernières entrées. --no-pager désactive le pager par défaut (less), qui bloquerait le terminal en attendant une interaction. -q neutralise les notifications de disponibilité qui s’affichent quand le journal n’est pas accessible. Cette commande peut signaler « No journal files were opened due to insufficient permissions. » ; ce cas est détaillé plus bas.
Limitez le nombre de lignes avec -n
journalctl -u cron.service -n 20 --no-pager -q
-n N (synonym --lines=N) limite la sortie aux N dernières entrées. Sans cette option, journalctl affiche tout l’historique disponible pour l’unité, ce qui peut être très long. L’option -n est le premier réflexe quand on ne sait pas combien d’entrées le journal contient.
Ne gardez que les erreurs avec -p err
journalctl -u cron.service -p err -n 10 --no-pager -q
Les priorités syslog vont de emerg (0, panique système) à debug (7, traces de mise au point), avec err (3) qui isole les erreurs. L’option -p err filtre les niveaux 3 et supérieurs : la sortie ne contient plus que les erreurs et ce qui est plus grave. C’est l’option qui transforme un déferlement de logs en signal lisible.
Bornez la période avec --since
journalctl -u cron.service --since "1 hour ago" -n 10 --no-pager -q
--since accepte une date ISO 8601 ("2026-09-14T10:00:00"), un mot-clé ("today", "yesterday", "1 hour ago", "2 days ago") ou un timestamp Unix. --until borne la période par le haut. Ces deux options sont utiles quand un incident a eu lieu à un moment précis et qu’on veut cibler la fenêtre temporelle.
Désactivez le pager avec --no-pager
Sans --no-pager, journalctl ouvre less (ou le pager défini par PAGER/SYSTEMD_PAGER). Dans un script, dans un terminal non interactif, ou simplement pour éviter d’appuyer sur q à la fin, --no-pager est l’option de référence. Cette page utilise systématiquement --no-pager pour la lisibilité des sorties.
Tenez --follow (-f) hors du parcours nominal
L’option -f (synonym --follow) garde journalctl ouvert et affiche les nouvelles entrées au fur et à mesure. C’est l’outil adapté pour observer un service en direct, mais elle bloque le terminal tant qu’on ne l’arrête pas avec Ctrl+C. Elle est documentée ici comme limite, pas exécutée dans le parcours. Pour un diagnostic ponctuel, -n suffit.
Pourquoi journalctl répond-il « No journal files were opened » ?
Ce message est le cas négatif classique du parcours. Il signale que journalctl n’a pas pu lire le journal système. Comprendre pourquoi aide à savoir quoi faire.
Identifiez le besoin d’appartenir à adm ou systemd-journal
journalctl -u cron.service -n 3 --no-pager -q
Sur Debian/Ubuntu par défaut, sur une machine où l’utilisateur courant n’est pas membre des groupes adm, systemd-journal ou wheel, la commande affiche :
No journal files were opened due to insufficient permissions.
avec un code retour qui varie selon la disponibilité d’un journal lisible (souvent 1 sans privilège, parfois 0 si un journal utilisateur est accessible). Ce n’est pas une erreur du shell : c’est journalctl qui signale que le journal système n’est pas accessible en lecture. Sans privilège root et sans appartenance à l’un de ces groupes, l’utilisateur ordinaire ne lit que son propre journal utilisateur.
Comprenez qui peut lire le journal système
Trois catégories d’utilisateurs accèdent au journal système complet : root (sans restriction), les membres du groupe systemd-journal (groupe dédié sur les distributions récentes), les membres du groupe adm (groupe historique pour les logs système), et les membres du groupe wheel sur certaines distributions. Si vous n’appartenez à aucun de ces groupes, la page doit adapter son parcours : remplacez le cas négatif par un journalctl filtré qui renvoie un journal utilisateur ou un journal vide, sans le message d’erreur.
Tentez le journal utilisateur avec --user
journalctl --user -n 3 --no-pager -q
Si aucune session utilisateur systemd n’a écrit de journal utilisateur, la commande affiche le même message « No journal files were opened due to insufficient permissions. » avec code retour 1. Le journal utilisateur n’est créé que si une session utilisateur systemd est active — c’est-à-dire si vous utilisez un gestionnaire de sessions compatible. Sur beaucoup de sessions de bureau, ce n’est pas le cas.
Refusez le réflexe sudo journalctl
sudo journalctl lève la restriction d’accès au journal. Ce n’est pas un automatisme : si vous n’avez pas de raison administrative documentée d’élever vos privilèges, restez en lecture utilisateur. Pour vérifier pourquoi journalctl refuse la lecture, contrôlez vos groupes avec id ; si le groupe adm ou systemd-journal manque, c’est une décision d’administration (ajout via usermod -aG, redémarrage de session) qui sort du périmètre débutant.
Que veut dire « Unit X.service could not be found » ?
Deuxième cas négatif du parcours : un nom de service mal orthographié. Le message est reconnaissable, et il ne faut pas le confondre avec un vrai échec de service.
Provoquez le cas sur un mauvais nom de service
systemctl status inconnu.service --no-pager
La commande affiche :
Unit inconnu.service could not be found.
avec un code retour 4 — la commande signale qu’elle n’a pas trouvé l’unité demandée (EXIT STATUS de systemctl(1) : 4 = « no such unit »). Ce n’est pas un crash : c’est un diagnostic qui dit « cette unité n’existe pas ».
Vérifiez l’orthographe et le suffixe .service
Le shell n’interprète pas le suffixe .service : il fait partie du nom de l’unité. Un nom sans suffixe (cron au lieu de cron.service) fonctionne parfois via expansion interne, mais un nom erroné déclenche le message ci-dessus. Pour vérifier qu’un nom correspond à un service installé :
systemctl list-unit-files --type=service --no-pager | grep cron
Cette commande liste les fichiers unit installés dont le nom contient cron. Comparez la sortie avec ce que vous avez tapé. L’orthographe et le suffixe sont les deux premières causes de ce message.
Distinguez « not-found » de « failed » et de « masked »
systemctl status affiche deux états distincts : un état de chargement (LOAD) et un état d’activation (ACTIVE). Le premier peut être loaded, not-found, bad-setting, error, ou masked. Le second peut être active, reloading, inactive, failed, activating, ou deactivating. Un service not-found n’est pas un service failed : le premier n’existe pas, le second a démarré puis s’est arrêté sur une erreur. Cette distinction évite de confondre une coquille avec un crash.
Reconnaissez l’état masked comme une protection à observer, pas à appliquer
Un service masked est lié à /dev/null : systemd refuse de le démarrer, automatiquement ou manuellement. C’est une protection forte, posée par un administrateur système pour empêcher un redémarrage accidentel d’un service dangereux. Ne reproduisez pas cette commande sans contexte ni documentation : systemctl mask rend le service totalement inerte. Si vous voyez un service masked dans une sortie, c’est un signal à observer, pas à imiter.
Comment redémarrer un service sans danger ?
Redémarrer un service est tentant quand quelque chose ne va plus. Mais c’est aussi l’opération qui peut casser une machine si elle vise le mauvais service.
Distinguez service système sensible et service d’exercice
Les services système sensibles sont ceux sur lesquels votre environnement s’appuie sans que vous y pensiez : cron (tâches planifiées), ssh ou sshd (connexion à distance), systemd-journald (le journal qu’on est en train de lire), systemd-logind (sessions utilisateur), NetworkManager ou systemd-networkd (connexion réseau). Aucun de ces services ne se redémarre à l’aveugle. Pour un exercice, utilisez plutôt un service utilisateur sans risque (par exemple un service que vous avez vous-même créé sous ~/.config/systemd/user/) ou un service d’exécution lancé via systemd-run --user --scope sans toucher au système.
Documentez systemctl restart sans l’exécuter sur un service sensible
systemctl restart nom.service
C’est la syntaxe de redémarrage d’un service. Elle arrête le service, puis le relance. Cette page ne l’exécute pas : la redémarrage d’un service système sensible exige un contexte d’administration documenté (ticket, fenêtre de maintenance, sauvegarde préalable). Pour le diagnostic de cette page, systemctl status, journalctl -u et la lecture du fichier unit suffisent.
Limitez l’usage de sudo systemctl
sudo systemctl élève la commande au niveau administrateur. Ce n’est pas un automatisme pour « que ça marche ». Si un service refuse de redémarrer, c’est peut-être qu’il ne doit pas être redémarré sans précaution. Vérifiez d’abord l’état avec systemctl status et les journaux avec journalctl -u : un redémarrage brutal peut masquer l’incident au lieu de le résoudre.
Gardez systemctl mask et systemctl daemon-reload hors du parcours
systemctl mask désactive complètement le démarrage (manuel et automatique). systemctl daemon-reload recharge la configuration de systemd après une modification d’unit file — il n’a aucun effet si aucun unit file n’a été modifié. Aucun de ces deux n’est demandé dans le parcours : ils relèvent d’une administration serveur documentée.
Comment le démarrage automatique est-il géré ?
Le démarrage automatique (enable/disable) est distinct du démarrage immédiat (start). Comprendre cette distinction évite de confondre les deux.
Affichez l’état d’activation avec is-enabled
systemctl is-enabled cron.service
La commande renvoie enabled et un code retour 0. « activé au boot » signifie que systemd lancera ce service au démarrage du système, automatiquement. Cela ne dit rien sur son état en ce moment : un service enabled peut être inactive ou failed selon ce qui lui est arrivé.
Documentez enable et disable sans les exécuter
systemctl enable nom.service
systemctl disable nom.service
enable ajoute les liens symboliques qui déclenchent le démarrage automatique au boot. disable retire ces liens. Aucun de ces deux n’est exécuté dans le parcours : la page se contente de vérifier l’état avec is-enabled.
Comprenez le statut static
Un service static n’a pas de section [Install] dans son unit file. Il ne peut pas être activé au boot via enable — il est démarré par un autre service qui le déclare comme dépendance (WantedBy=, Requires=). Tenter systemctl enable sur un service static renvoie un message d’erreur. Ce statut est une information, pas une anomalie.
Mentionnez systemctl list-dependencies en lecture seule
systemctl list-dependencies cron.service --no-pager
La sortie affiche l’arbre des dépendances : ce qui doit être démarré avant ce service, et ce qui le démarrera. Cette commande est en lecture seule : elle informe sur la chaîne de démarrage, sans la modifier.
Quelles opérations faut-il laisser de côté quand on débute ?
Quatre familles d’opérations méritent leur propre parcours et ne sont pas illustrées ici.
Pourquoi sudo systemctl restart, enable, mask et daemon-reload restent hors du parcours nominal
sudo systemctl restart redémarre un service avec privilège, ce qui peut arrêter une tâche en cours. enable et disable modifient le démarrage automatique au boot, ce qui peut casser un service attendu au démarrage. mask rend le service totalement inerte. daemon-reload recharge la configuration de systemd. Chacune mérite son propre repère, construit séparément, avec des sources et un environnement de test isolés.
Pourquoi l’édition d’unit file (/etc/systemd/system/, drop-ins) reste hors du parcours
Modifier un fichier dans /etc/systemd/system/ ou créer un drop-in dans /etc/systemd/system/mon.service.d/ exige une compréhension des directives [Unit], [Service] et [Install], et un protocole de relecture précis (sauvegarde, validation, redémarrage du service). Cette page n’aborde ni la création ni l’édition d’unit file. Pour un parcours plus avancé, la documentation officielle systemd reste la référence.
Avant toute intervention sur ces fichiers, revoyez Permissions et utilisateurs Linux : comprendre avant de modifier : comprendre qui peut lire, écrire ou exécuter un fichier du système évite de modifier un unit file avec de mauvais droits.
Pourquoi les services réseau (NetworkManager, systemd-networkd, systemd-resolved) sont ailleurs
Le diagnostic des connexions réseau (Wi-Fi, Ethernet, DNS) suit une logique distincte : il croise NetworkManager, systemd-networkd, systemd-resolved, ip, ss, resolvectl et des journaux différents. Cette page s’arrête au strict « service » et « journal » d’une unité générique ; la fiche sœur couvre le diagnostic réseau quand elle sera publiée.
Pourquoi le durcissement systemd est ailleurs
Le durcissement (hardening) systemd traite systemd-analyze security, ProtectSystem=, ProtectHome=, NoNewPrivileges=, RestrictAddressFamilies=, SystemCallFilter=. Ces directives relèvent d’une démarche de sécurité documentée, distincte du diagnostic de service. La page courante n’aborde ni la sécurité, ni le score, ni les recommandations.
Où aller ensuite pour un parcours plus large ?
Pour un tour d’horizon plus large du terminal, partez de la section Linux et terminal de CyberSDF. Pour un parcours de survie plus structuré, le guide de survie en ligne de commande couvre l’essentiel d’un terminal GNU. Pour reprendre les premières commandes avant ce parcours, Commandes Linux de base : se repérer, créer et copier sans risque est la page qui prépare le terrain.
Pour retrouver les fichiers et dossiers manipulés ici (/etc/systemd/system/, /var/log/journal/, /usr/lib/systemd/system/) et savoir les lire sans les déplacer, voir Fichiers et répertoires Linux : les manipuler sans perte.
Questions fréquentes avant de continuer
Quelle différence entre systemctl status et journalctl -u ?
systemctl status affiche l’état instantané d’un service (LOAD, ACTIVE, SUB, PID, mémoire, CPU, CGroup) plus les dernières lignes du journal, le tout en une seule commande. journalctl -u affiche l’historique complet des journaux d’une unité, sans état instantané : c’est l’outil pour explorer le passé d’un service. Les deux se complètent : status pour le présent, journalctl -u pour le déroulé.
Pourquoi journalctl affiche-t-il « No journal files were opened due to insufficient permissions » ?
Parce que l’utilisateur courant n’est pas membre des groupes adm, systemd-journal ou wheel. Seuls root et ces groupes lisent le journal système complet. Un utilisateur ordinaire ne lit que son propre journal utilisateur, et seulement si une session utilisateur systemd est active.
Comment reconnaître un service « failed » ?
systemctl status affiche Active: failed (Result: exit-code) quand le service a quitté sur un code d’erreur, ou Active: failed (Result: signal) quand il a été tué par un signal. Pour lister tous les services en échec :
systemctl list-units --type=service --failed --no-pager
Pour les erreurs récentes d’une unité précise, croisez avec journalctl -u nom.service -p err -n 50 --no-pager -q.
Que faire si je dois redémarrer un service système sensible ?
Un service système sensible (cron, ssh, systemd-journald) ne se redémarre pas à l’aveugle. Ouvrez un ticket d’administration ou consultez la documentation Debian Handbook plutôt que d’improviser un sudo systemctl restart. Cette page ne propose pas de procédure privilégiée pour ces services.
Comment savoir si je peux quitter l’exercice ?
Vous pouvez fermer le terminal à tout moment : aucune commande de cette page ne modifie l’état du système, aucun fichier d’unit file n’est touché, aucun service n’est redémarré, aucun privilège n’est élevé. Pour une revisite, relancez simplement systemctl list-units --type=service --no-pager --no-legend pour revoir la liste.
Quelle différence entre systemctl list-units et systemctl list-unit-files ?
list-units liste les unités actuellement en mémoire, chargées par systemd. list-unit-files liste les unités installées sur le disque (fichiers .service, .timer, etc.). Un service peut être installé sans être chargé (par exemple après une installation sans redémarrage), et inversement un service peut être en mémoire sans apparaître dans list-unit-files s’il a été lancé manuellement par un autre mécanisme.