Notes › _DIFFUSION

---
title:
  name:
  level:
  center:
exclude:
style:
  listType:
omit:
levels:
  min:
  max:
---

# Table of Contents

- Comment utiliser systemctl sur Linux
- Systemctl Linux : utilisation et exemples
    - Comment lister tous les services avec leurs statuts
    - Comment afficher le statut d’un service : démarré, arrêté, failed
    - Comment afficher la configuration d’un service avec systemctl
    - Comment démarrer, arrêter, recharger, redémarrer un service avec systemctl
    - Comment recharger la configuration d’un service avec systemctl daemon-reload
    - Comment activer un service au démarrage avec systemctl
    - Comment désactiver un service au démarrage avec systemctl
    - Comment afficher les services en erreur
    - Comment lister les dépendances d’un service
    - Comment masquer un service avec systemd
- Vérifier et dépanner les services Linux
- Comment utiliser journalctl pour voir et manipuler les journaux Systemd
    - Comment consulter les journaux Linux avec journalctl
    - Afficher les journaux en inversé
    - Lire le journal de démarrage du système linux
    - Filtrer les journaux sur le temps
    - Afficher les entrées dont le MESSAGE correspond à un PATTERN
    - Afficher les journaux d’un daemon
    - Filtrer les journaux sur un utilisateur
    - Visualiser les journaux du noyau Linux
    - Afficher les erreurs dans les journaux
    - Afficher les journaux d’un service/daemon en particulier
    - Utiliser l’option tail avec journalctl
    - Changer le format de sortie
    - Visualiser l’espace disque utilisé par les journaux
    - Fixer la taille et le nombre de journaux
- Diagnostiquer un service qui ne fonctionne plus
- Vérifier et dépanner un service sous Linux avec systemctl et journalctl
    - Lister les services Linux
    - Vérifier les services en échec
    - Vérifier un service en particulier
    - Comprendre l’état Active
    - Repérer le code d’erreur
    - Consulter les services qui ont échoué après le démarrage
- Consulter les logs d’un service
    - Afficher les derniers événements
    - Afficher les logs depuis une période précise
    - Suivre les logs en temps réel
    - Rechercher les erreurs importantes
- Activer ou désactiver un service au démarrage
    - Activer un service au démarrage
    - Désactiver un service au démarrage
    - Ne pas confondre disable et mask
- Vérifier pourquoi un service ne démarre pas
    - Vérifier si un port est déjà utilisé
    - Vérifier les permissions
    - Rechercher un manque de mémoire ou un crash
- Vérifier la configuration avant de redémarrer un service
- Réinitialiser l’état failed d’un service
- Vérifier les dépendances d’un service
    - Rechercher les dépendances inverses
    - Comprendre les relations entre les unités
- Vérifier le fichier unit systemd
    - Identifier l’emplacement du fichier unit
    - Vérifier les personnalisations d’un service
- Recharger systemd après modification d’un service
    - Ne pas confondre daemon-reload, reload et restart
- Tableau des commandes systemctl pour dépanner un service

Comment utiliser systemctl sur Linux

Voici la syntaxe de la commande systemctl :

systemctl [commande] [Nom service]

La liste des commandes possibles :

Commandes	Description
list-units	Lister les unités systemd
start	Démarrer un service
stop	Arrêter un service
mask	Masquer un service
status	Vérifier le statut du service
restart	Redémarrer le service
reload	Recharger un ou plusieurs services
reload-or-restart	Recharger le service sinon le redémarrer
try-restart	Redémarre le service si actif
kill	Envoie un signal aux processus de l’unité/service comme la commande kill Utilisez –kill-who= pour sélectionner à quel processus envoyer le signal Utilisez –signal= pour sélectionner le signal à envoyer
daemon-reload	Recharger la configuration des services
reload-or-restart	Recharger une ou plusieurs unités s’ils le soutiennent
is-active	Vérifie si le service/unité est actif
is-failed	Vérifie si le service a le statut failed
show	Affiche la configuration et les propriétés d’une unité/service
edit	Editer le fichier de configuration de l’unité/service
clean	Nettoyer les runtime, cache, state, logs ou configuration de l’unité

Les principales commandes sur les unités/services de systemctl

Plus de commandes avec :

systemctl --help

Systemd utilise un concept d’unit, qui peut être un service, sockets, point de montage, périphériques, etc.
Les fichiers de configuration sont stockés dans /lib/systemd/system/

Systemctl Linux : utilisation et exemples

Comment lister tous les services avec leurs statuts

La commande systemctl permet d’interroger systemd afin de connaître la liste des unités (dont les services) et leurs états.
Pour lister tous les unités quelques soit le type, on utilise le paramètre list-units :

systemctl list-units 

Si l’on veut filtrer la liste par type (services, socket, …), on utilise le paramètre –type.
Par exemple pour lister les services systemd :

systemctl list-units --type service

Voici le contenu de la sortie :

• UNIT : Le nom de l’unité
• LOAD : Si le fichier de configuration de l’unité a été chargé avec susccès
• ACTIVE : Etat du service actif/inactif
• SUB : Sous-état de l’unité qui varie selon le type d’unité
• DESCRIPTION : La description du service

Ce tableau récapitule les états possibles d’une unité et d’un service :

Statut	Description
loaded	Le fichier de configuration de l’unité a été traité et traité avec succès.
Active (exited)	Exécuté avec succès la configuration ponctuelle et après l’exécution, l’appareil n’exécute ni le processus actif ni l’attente d’un événement.
Active (running)	Exécutez avec succès la configuration ponctuelle et après l’exécution, l’appareil exécute un ou plusieurs processus actifs.
Active (waiting)	Exécuté avec succès la configuration unique et après l’exécution, l’appareil attend un événement.
Inactive (dead)	Soit la configuration ponctuelle n’a pas réussi à exécuter ou non exécuté.

Les états (states) de systemd

Pour filtrer sur un état, on utilise le paramètre –state :

systemctl list-units --all --state=inactive

Pour lister tous les services quelque soit leurs états :

systemctl list-unit-files --type service -all

• UNIT File : qui est le fichier de l’unité, ici on filtre sur le type service, ainsi on a que des fichiers XXXXX.service
• STATE : l’état du service (voir tableau ci-dessous)
• VENDOR PRESET : la configuration par défaut

Comment afficher le statut d’un service : démarré, arrêté, failed

Comment savoir si un service est démarré, en cours de fonctionnement ou arrêté ?
Pour vérifier, systemctl fournit l’option statuts :

systemctl status [Nom service] 

Pour vérifier si un service a le statut actif et démarré :

systemctl is-active [Nom service]

Comment afficher la configuration d’un service avec systemctl

systemctl est aussi capable d’afficher les propriétés d’une unité et d’un service.
Pour cela on utilise la commande show comme ceci :

systemctl show [Nom service]

Par exemple pour afficher les propriétés du service cron :

systemctl show cron

La sortie affiche les propriétés et la configuration complète en liste.

Comment démarrer, arrêter, recharger, redémarrer un service avec systemctl

La principale utilisation de systemctl dans la gestion des services est de changer le statut d’un service.
C’est à dire démarrer ou arrêter un service ou encore le redémarrer.

On utilise les trois commandes suivantes :

• start : démarre un service
• stop : arrête un service
• restart : redémarre un service, ce qui équivaut à un stop puis un start

systemctl start [Nom service]
systemctl stop [Nom service]
systemctl restart [Nom service] 

Par exemple, pour redémarrer nginx :

systemctl restart nginx.service

La commande reload permet de relire le fichier de configuration.
Elle est idéale après une modification de la configuration d’un service pour prendre en compte les modifications.
Étant donné que la recharge ne recharge que la configuration, elle entraînera moins de perturbation des activités existantes et des connexions actuellement ouvertes.
Les utilisateurs peuvent même ne pas remarquer que c’était couru.
Cependant, selon le serveur dont nous parlons, certaines options peuvent ne pas être modifiables à l’aide de rechargement.
Et si le serveur utilise trop de mémoire, etc., il peut être nécessaire d’utiliser le redémarrage pour le forcer à partir d’une ardoise propre.

La syntaxe est la même, ainsi pour recharger le service nginx :

systemctl reload nginx.service

Comment recharger la configuration d’un service avec systemctl daemon-reload

L’option daemon-reload pour recharger la configuration du gestionnaire systemd.
Cela relancera tous les générateurs rechargera tous les fichiers d’unité et recréez l’intégralité de l’arbre de dépendances. Pendant le rechargement du démon, tous les sockets
systemd écoute au nom de la configuration de l’utilisateur restera accessible.

systemctl daemon-reload

Comment activer un service au démarrage avec systemctl

On utilise l’option enable suivi du nom du service.
Voici la syntaxe par défaut à utiliser :

sudo systemctl enable SERVICE_NAME

Par exemple pour désactiver le nom du service scan de clamd :

systemctl enable clamd@scan.service

Comment désactiver un service au démarrage avec systemctl

De même il est possible de désactiver un service du démarrage Linux avec systemctl.
Pour cela, on utilise l’option disable comme expliqué ci-dessous :

sudo systemctl disable SERVICE_NAME

Par exemple pour déactiver le service clamd du démarrage de Linux :

systemctl disable clamd@scan.service

Comment afficher les services en erreur

Utilisez –state=failed ou –failed pour n’afficher que les unités défaillantes.

sudo systemctl --failed

Après avoir identifié les unités défaillantes, nous pouvons résoudre leur état en utilisant l’une des commandes suivantes :

systemctl reset-failed

systemctl reset-failed <nom service>

Comment lister les dépendances d’un service

systemctl permet aussi d’interroger un service et lister les dépendances.
Il s’agit des services nécessaires au fonctionnement de ce dernier.
Si un des services dépendants n’est pas démarré, vous ne pourrez pas démarrer le service.

systemctl list-dependencies --all nginx.service

Comment masquer un service avec systemd

Enfin systemd propose une commande mask qui permet de masquer une unité dont un service.
Le service est alors considéré comme étant totalement désactivé.
A partir de là, il est impossible de démarrer le service.

systemctl mask nginx.service

systemd créé alors un lien symbolique qui fait pointer le fichier du service vers /dev/null

Le démarrage du service est impossible et on rencontre une erreur du type :

Failed to start nginx.service: Unit nginx.service is masked.

On utilise la commande umask pour retirer l’état masquer d’un service.
Cela réactive le service et il est alors possible de le démarrer à nouveau.

systemctl unmask nginx.service

Vérifier et dépanner les services Linux

Lorsqu’un service ne démarre plus, s’arrête de manière inattendue ou fonctionne mal, les commandes systemctl et journalctl permettent généralement d’en identifier rapidement la cause. Vous pouvez vérifier son état, rechercher les services en échec, consulter leurs journaux et détecter une erreur de configuration, un problème de permissions, une dépendance manquante, un port déjà utilisé ou un crash du processus.

Le guide suivant détaille les principales méthodes pour diagnostiquer et réparer un service géré par systemd, ainsi que les commandes à utiliser pour le démarrer, le redémarrer ou vérifier ses dépendances et son fichier unit.

---

Comment utiliser journalctl pour voir et manipuler les journaux Systemd

Sur Linux, les journaux (logs) sont une partie importante du système car elles vous permet d’audit, surveiller le système.
On peut aussi les utiliser pour dépanner le système ou un service qui ne fonctionne pas correctement.
Linux créé par défaut beaucoup de journaux (syslog, messages, auth, daemon, …) dans le répertoire /var/log.
Cette journalisation centralisée s’effectue à travers SystemD qui recueille et stocke des données de journalisation des noyaux, des messages de journal système, une sortie standard et une erreur pour les divers services.
Plus particulièrement, c’est le daemon journald qui gère les sources des journaux pour une sortie format syslog, JSON, …

Enfin la commande journalctl permet à l’administrateur d’interroger et consulter les journaux.
Elle permet aussi de manipuler les journaux, comme par exemple vider les journaux.
journalctl est donc important à connaître pour le débogage du système.

Comment consulter les journaux Linux avec journalctl

La commande par défaut affiche tous les journaux.
Bien entendu, on peut appliquer toutes sortes d’options pour filtrer les journaux sur une date, un service en particulier.

journalctl

Cela va retourner beaucoup de lignes.
JournalCtl utilise la commande less pour vous montrer les journaux.
Ce qui signifie que vous pouvez utiliser les mêmes raccourcis clavier pour vous déplacer dans les journaux que vous le faites avec la commande less.

Si vous ne voulez pas que les journaux soient affichés avec less, utilisez l’option –no-pager :

journalctl --no-pager

Cela permet notamment d’utiliser la commande grep pour filtrer.

Afficher les journaux en inversé

Comme vous l’avez remarqué, les journaux sont montrés dans l’ordre chronologique. Cela signifie que les journaux stockés les plus anciens sont affichés en premier.
Si vous souhaitez d’abord voir les journaux récents, vous pouvez afficher les journaux de journal dans l’ordre inverse avec l’option -r:

journalctl -r

Lire le journal de démarrage du système linux

Pour afficher les journaux du dernier démarrage de Linux (boot) :

journalctl -b

Pour afficher la liste des journaux de démarrages disponibles :

journalctl --list-boots

Cela retourne la liste des journaux disponible avec un identifiant :

-2 ezsdfzeerg8fds9qger4ger8ede9ver Sun 2021-08-08 22:12:23 UTC—Mon 2021-08-08 22:12:23 UTC
-1 e5f4ds5ferhtrh4tyj5trez6ezfer8d Mon 2021-08-09 11:22:13 UTC—Mon 2021-08-09 11:22:13 UTC
0 cf61e3c7347b41308468e0431ee77ade Mon 2021-08-09 16:39:41 UTC—Mon 2021-08-09 16:42:27 UTC

Pour voir les journaux du démarrage précédent de Linux, on utilise l’option -b=-X.
Réduisez le chiffre pour remontrer aux journaux des boots précédents selon les disponibilités.
Par exemple :

journalctl -b=-1

Notez que l’on peut aussi afficher les logs du démarrage de Linux via l’identifiant :

journalctl -b e5f4ds5ferhtrh4tyj5trez6ezfer8d

Filtrer les journaux sur le temps

Mais on peut aussi remonter dans les logs précédents pour un service en particulier grâce à l’option -S (Since).
Par exemple, vous pouvez visualiser les journaux du jour, de la veille, 1h ou deux jours avant.

journalctl -S today
journalctl -S yesterday
journalctl --since "5 minutes ago"
journalctl --since "25 minutes ago"
journalctl -S "1 hour ago"
journalctl -S "2 days ago"

Enfin vous pouvez spécifier un intervalle de date avec l’option -S (since) et -U (until).

journalctl -S "2020-01-16 18:00:00" -U "2020-01-17 23:00:00"

Notez que l’on peut aussi utiliser les options avec le nom complet, par exemple :

journalctl --since=yesterday --until=now

Afficher les entrées dont le MESSAGE correspond à un PATTERN

Vous pouvez utiliser l’option -g si vous souhaitez afficher les journaux avec un mot en particulier.
Par exemple, ci-dessous, je souhaite afficher que les journaux correspondant au mot nvidia :

journalctl -b -g nvidia

Afficher les journaux d’un daemon

Vous pouvez filtrer les journaux pour n’afficher que les logs d’un daemon et service spécifique.
Par exemple, pour ne voir que les journaux du service ssd avec l’option -u (pour unit) :

journalctl -u ssh

Ou encore pour afficher les journaux de nginx :

journalctl -u nginx

Au besoin pour lister les units :

systemctl list-dependencies

Bien entendu, on peut combiner avec les options précédentes :

sudo journalctl -u ssh --since=yesterday
sudo journalctl -u ssh -b0

On peut aussi filtrer les logs par GID.
Pour afficher les GID :

journalctl -F _GID
1000
65534
0
115
112

Puis on utilise l’option _GID pour filtrer sur ce dernier.

journalctl _GID=115
-- Logs begin at Mon 2021-08-09 16:39:41 UTC, end at Tue 2021-08-10 07:31:56 UTC. --
Aug 09 16:39:55 ns320684 mysqld[622]: 2021-08-09 16:39:55 0 [Note] /usr/sbin/mysqld (mysqld 10.3.29-MariaDB-0+deb10u1) starting as process 622 ...

Filtrer les journaux sur un exécutable :

journalctl /usr/bin/sudo
-- Logs begin at Mon 2021-08-09 16:39:41 UTC, end at Tue 2021-08-10 07:32:40 UTC. --
Aug 09 16:42:27 ns320684 sudo[1074]:   debian : TTY=pts/0 ; PWD=/home/debian ; USER=root ; COMMAND=/usr/bin/journalctl --list-boots
Aug 09 16:42:27 ns320684 sudo[1074]: pam_unix(sudo:session): session opened for user root by debian(uid=0)
Aug 09 16:42:27 ns320684 sudo[1074]: pam_unix(sudo:session): session closed for user root
Aug 10 07:16:52 ns320684 sudo[19215]:   debian : TTY=pts/0 ; PWD=/home/debian ; USER=root ; COMMAND=/usr/bin/journalctl --vacuum-time=2d
Aug 10 07:16:52 ns320684 sudo[19215]: pam_unix(sudo:session): session opened for user root by debian(uid=0)
Aug 10 07:16:52 ns320684 sudo[19215]: pam_unix(sudo:session): session closed for user root
Aug 10 07:16:57 ns320684 sudo[19218]:   debian : TTY=pts/0 ; PWD=/home/debian ; USER=root ; COMMAND=/usr/bin/journalctl --vacuum-time=1d
Aug 10 07:16:57 ns320684 sudo[19218]: pam_unix(sudo:session): session opened for user root by debian(uid=0)
Aug 10 07:16:57 ns320684 sudo[19218]: pam_unix(sudo:session): session closed for user root

Filtrer les journaux sur un utilisateur

On récupérer l’ID de l’utilisateur avec la commande id :

debian@linux:~$ id -u debian
1000

Puis pour filtrer les journaux sur un utilisateur sur les 25 dernières minutes :

debian@linux:~$ journalctl _UID=1000 --since "25 minutes ago"
-- Logs begin at Mon 2021-08-09 16:39:41 UTC, end at Tue 2021-08-10 07:33:29 UTC. --
Aug 10 07:11:58 ns320684 systemd[19113]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Aug 10 07:11:58 ns320684 systemd[19113]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Aug 10 07:11:58 ns320684 systemd[19113]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Aug 10 07:11:58 ns320684 systemd[19113]: Reached target Timers.
Aug 10 07:11:58 ns320684 systemd[19113]: Listening on GnuPG cryptographic agent and passphrase cache.
Aug 10 07:11:58 ns320684 systemd[19113]: Listening on GnuPG network certificate management daemon.
Aug 10 07:11:58 ns320684 systemd[19113]: Reached target Sockets.
Aug 10 07:11:58 ns320684 systemd[19113]: Reached target Paths.
Aug 10 07:11:58 ns320684 systemd[19113]: Reached target Basic System.
Aug 10 07:11:58 ns320684 systemd[19113]: Reached target Default.
Aug 10 07:11:58 ns320684 systemd[19113]: Startup finished in 28ms.

Visualiser les journaux du noyau Linux

Pour afficher les journaux du noyaux Linux (kernel), équivaut à la commande dmesg :

journalctl -k

Afficher les erreurs dans les journaux

Afficher les erreurs dans les journaux où -p 3 signifie priorité ERR, -X fournit des informations de message supplémentaires et -b signifie depuis le dernier démarrage.

journalctl -p 3 -xb

Il s’agit en fait de filtrer sur les niveaux de priorité :

Priorité	Code
0	emerg
1	alert
2	crit
3	err
4	warning
5	notice
6	info
7	debug

Les priorités des journaux Linux

L’option -p prenant les intervalles de priorité, par exemple pour avoir les alertes, critiques, erreur et warning :

journalctl -p 1..3

Afficher les journaux d’un service/daemon en particulier

Pour afficher les erreurs des journaux pour un service en particulier, utilisez l’option -u :

journalctl -u sshd.service

Filtrer sur un service avec l’option –no-pager et en récupérant les erreurs :

journalctl -u docker.service --no-pager | grep -i error

Utiliser l’option tail avec journalctl

Afficher les 100 lignes de Systemd Logs pour un service particulier (Equiv. Tail-N 100):

sudo journalctl -u nginx -n 100 --no-pager

Suivez les journaux SystemD pour le service (Equiv. Tail -F).
Les nouvelles lignes du journal pour le service vont alors s’afficher au fur et à mesure.

sudo journalctl -u nginx -f

Pour afficher les derniers journaux :

journalctl -xe

Changer le format de sortie

L’option -o permet de modifier le format de sortie.
Par exemple pour afficher les journaux au format JSON :

journalctl -b -u nginx -o json

Journalctl gère plusieurs format dont :

• cat : texte plein
• export : un format binaire adapté au transfert ou à la sauvegarde de données.
• json : en JSON
• json-pretty : JSON formaté pour une meilleure lisibilité par l’homme
• json-sse : résultat formaté sous JSON enveloppé pour que l’événement add server-sen soit compatible
• short : la sortie de style syslog par défaut
• short-iso : affiche les horodatages d’horloge murale ISO 8601
• short-monotonic : le format par défaut avec des horodatages monotones.
• short-precise : le format par défaut avec précision à la microseconde près
• verbose : affiche chaque champ de journal disponible pour l’entrée, y compris ceux généralement cachés en interne.

Visualiser l’espace disque utilisé par les journaux

journalctl --disk-usage

Fixer la taille et le nombre de journaux

Vous pouvez limiter le nombre de fichiers journaux d’archive. Disons que vous voulez avoir seulement cinq fichiers journaux.
Il supprimera les fichiers journaux d’archive les plus âgés ne laissant que le nombre spécifié de fichiers journaux.

journalctl --vacuum-files=5

Une autre façon est de limiter la taille du journal. Avec cela, il supprimera les fichiers journaux de journal jusqu’à ce que l’espace disque pris par les journaux de journal tombe en dessous de la taille que vous avez spécifiée.

sudo journalctl --vacuum-size=100M

Diagnostiquer un service qui ne fonctionne plus

Un service Linux qui passe dans l’état failed, refuse de démarrer ou s’arrête quelques secondes après son lancement peut avoir de nombreuses causes : configuration incorrecte, droits insuffisants, dépendance indisponible, port déjà occupé ou erreur de l’application.

Avec systemctl, vous pouvez contrôler l’état du service et identifier les unités en échec, tandis que journalctl permet d’examiner les messages enregistrés au moment du problème. Ces deux outils constituent donc la base du dépannage des services sur les distributions utilisant systemd.

---

Vérifier et dépanner un service sous Linux avec systemctl et journalctl

Lister les services Linux

Sur la plupart des distributions Linux récentes, les services sont gérés par systemd. La commande systemctl permet de les lister, vérifier leur état, les démarrer ou les arrêter et diagnostiquer les services qui rencontrent des erreurs.

Pour afficher les services actuellement chargés par systemd, utilisez :

systemctl list-units --type=service

La commande affiche notamment le nom du service, son état de chargement et son état d’exécution.

Colonne	Description
UNIT	Nom de l’unité systemd, par exemple nginx.service ou ssh.service
LOAD	Indique si le fichier de configuration du service a été correctement chargé
ACTIVE	État général du service : active, inactive, failed, etc.
SUB	État plus précis du service : running, exited, dead, failed, etc.
DESCRIPTION	Description du service

Par défaut, list-units affiche principalement les unités actuellement chargées. Pour afficher tous les services installés, y compris ceux qui ne sont pas actuellement actifs, utilisez plutôt :

systemctl list-unit-files --type=service

Cette commande permet également de connaître leur configuration au démarrage, avec des états tels que enabled, disabled, static ou masked.

Pour afficher uniquement les services actuellement actifs :

systemctl list-units --type=service --state=running

Et pour rechercher un service particulier, vous pouvez filtrer la sortie. Par exemple, pour PHP :

systemctl list-units --type=service | grep -i php

ou pour Nginx :

systemctl list-units --type=service | grep -i nginx

Enfin, si votre objectif est de rechercher directement les services rencontrant un problème, inutile de parcourir toute la liste. systemctl dispose d’une commande dédiée permettant d’afficher uniquement les unités en échec :

systemctl --failed

C’est cette commande qu’il est recommandé d’utiliser en premier lorsqu’un service ne fonctionne plus ou après un problème système.

Vérifier les services en échec

Lorsqu’une application ne fonctionne plus ou qu’un serveur présente un dysfonctionnement, commencez par vérifier si systemd a détecté des services en échec.

La commande suivante affiche toutes les unités actuellement dans l’état failed :

systemctl --failed

Vous pouvez obtenir par exemple :

UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
php8.4-fpm.service    loaded failed failed The PHP 8.4 FastCGI Process Manager

Les colonnes ACTIVE et SUB indiquent ici que le service a échoué. Cela signifie que systemd a tenté de le démarrer ou de le maintenir en fonctionnement, mais qu’une erreur l’en a empêché.

Pour limiter la recherche aux services :

systemctl --failed --type=service

Vérifier un service en particulier

Si vous connaissez le nom du service en panne, affichez directement son état avec :

systemctl status nom-du-service

Par exemple :

systemctl status php8.4-fpm

ou :

systemctl status nginx

La sortie de systemctl status fournit plusieurs informations importantes :

• Loaded : indique si l’unité systemd a été correctement chargée.
• Active : indique si le service est actif, arrêté ou en échec.
• Main PID : PID du processus principal lorsqu’il fonctionne.
• Result : raison générale de l’échec.
• Process / ExecStart : commande ayant été exécutée par systemd.
• Les derniers messages du journal associés au service.

Vous pouvez par exemple rencontrer :

Active: failed (Result: exit-code)

Cela indique que le programme lancé par systemd s’est terminé avec un code de retour indiquant une erreur. Il faut alors rechercher le message qui explique pourquoi le programme s’est arrêté.

Comprendre l’état Active

Le champ Active permet de connaître rapidement la situation du service.

État	Signification
active (running)	Le service fonctionne normalement
active (exited)	La commande du service s’est terminée correctement, mais aucun processus ne reste actif. Cela peut être normal pour certains services
inactive (dead)	Le service n’est actuellement pas démarré
failed	Le service a tenté de fonctionner mais a rencontré une erreur
activating	Le service est en cours de démarrage
deactivating	Le service est en cours d’arrêt

Un état active (exited) n’est donc pas nécessairement une erreur. Certains services de type oneshot exécutent une tâche puis se terminent normalement.

Repérer le code d’erreur

Lorsqu’un service échoue, recherchez particulièrement les lignes Result, code et status.

Par exemple :

Active: failed (Result: exit-code)

puis :

code=exited, status=1/FAILURE

Cela signifie que le programme a été lancé mais s’est terminé avec un code d’erreur.

Vous pouvez également rencontrer :

• Result: timeout : le service n’a pas terminé son démarrage ou son arrêt dans le délai prévu.
• Result: signal : le processus a été terminé par un signal.
• Result: core-dump : le processus a planté et généré un core dump.
• Result: exit-code : le programme s’est terminé avec un code d’erreur.
• Result: watchdog : le service n’a pas répondu au mécanisme watchdog dans le délai prévu.

Les dernières lignes affichées par systemctl status donnent souvent une première indication sur l’origine du problème. Toutefois, elles ne représentent qu’une partie des journaux.

Pour obtenir l’historique complet et déterminer pourquoi le service a échoué, l’étape suivante consiste à consulter ses logs avec journalctl -u.

Consulter les services qui ont échoué après le démarrage

Après un redémarrage, il peut être utile d’exécuter :

systemctl --failed

Un service secondaire en échec n’indique pas nécessairement un problème grave. En revanche, si un composant essentiel comme SSH, Nginx, Apache, PHP-FPM, MariaDB/MySQL ou un service réseau apparaît dans cette liste, son échec peut expliquer directement le dysfonctionnement rencontré.

Ne redémarrez pas systématiquement le service immédiatement. Commencez plutôt par consulter son état et ses journaux, afin de conserver les informations permettant d’identifier la cause de l’échec.

La prochaine étape consiste donc à utiliser systemctl status, puis journalctl -u pour déterminer précisément pourquoi le service ne démarre plus.

Consulter les logs d’un service

La commande journalctl permet de consulter les journaux enregistrés par systemd pour un service particulier. C’est l’une des commandes les plus importantes pour comprendre pourquoi un service ne démarre pas, s’arrête brutalement ou rencontre des erreurs.

Pour afficher les journaux d’un service, utilisez l’option -u suivie du nom de l’unité :

sudo journalctl -u nom-du-service

Par exemple, pour Nginx :

sudo journalctl -u nginx

Ou pour PHP-FPM :

sudo journalctl -u php8.4-fpm

Afficher les derniers événements

Lorsque le journal contient beaucoup d’entrées, utilisez l’option -e pour vous positionner directement à la fin :

sudo journalctl -u nginx -e

Vous pouvez également afficher uniquement les dernières lignes :

sudo journalctl -u nginx -n 50

Cela permet de retrouver rapidement les événements enregistrés juste avant l’arrêt ou l’échec du service.

Afficher les logs depuis une période précise

Pour limiter l’analyse aux événements récents :

sudo journalctl -u nginx --since "1 hour ago"

Ou depuis une date et une heure précises :

sudo journalctl -u nginx --since "2026-08-07 08:00:00"

Vous pouvez également définir une période :

sudo journalctl -u nginx --since "2026-08-07 08:00:00" --until "2026-08-07 09:00:00"

Cette méthode est particulièrement utile lorsque vous connaissez approximativement l’heure à laquelle le service est tombé en panne.

Suivre les logs en temps réel

Pour afficher les nouveaux événements au fur et à mesure qu’ils sont générés, utilisez l’option -f :

sudo journalctl -u nginx -f

Laissez cette commande ouverte puis, dans un autre terminal, redémarrez le service ou reproduisez le problème. Vous pourrez ainsi observer immédiatement les erreurs générées.

Utilisez Ctrl + C pour arrêter le suivi.

Rechercher les erreurs importantes

Portez notamment attention aux messages contenant :

• failed ou failure : échec d’une opération.
• permission denied : problème de permissions.
• address already in use : un autre processus utilise déjà le port nécessaire.
• out of memory ou killed process : manque de mémoire.
• segfault ou core dumped : plantage du programme.
• timeout : délai d’attente dépassé.
• dependency failed : une dépendance nécessaire au service est en échec.
• configuration error ou syntax error : erreur dans un fichier de configuration.

Il est également important de vérifier les logs propres à l’application. journalctl peut indiquer qu’un service a échoué sans contenir tous les détails. Nginx, Apache, PHP-FPM, MariaDB ou d’autres applications peuvent écrire des informations supplémentaires dans leurs propres fichiers sous /var/log/.

Après avoir identifié le message d’erreur, évitez de redémarrer le service en boucle. Vérifiez d’abord sa configuration, ses permissions, ses ports et ses dépendances afin de corriger la cause réelle de l’échec.

Activer ou désactiver un service au démarrage

Par défaut, tous les services Linux ne sont pas automatiquement lancés au démarrage du système. Avec systemd, la commande systemctl permet de vérifier si un service est configuré pour démarrer automatiquement, puis d’activer ou de désactiver ce comportement.

Pour vérifier l’état d’un service au démarrage :

systemctl is-enabled nom-du-service

Par exemple :

systemctl is-enabled nginx

La commande peut notamment retourner :

• enabled : le service est activé au démarrage.
• disabled : le service existe mais n’est pas activé automatiquement.
• static : le service ne peut pas être activé directement et est généralement lancé comme dépendance d’une autre unité.
• masked : le service est complètement bloqué et ne peut pas être démarré normalement.

Activer un service au démarrage

Pour configurer un service afin qu’il démarre automatiquement avec Linux :

sudo systemctl enable nom-du-service

Par exemple :

sudo systemctl enable nginx

La commande enable n’a pas pour rôle de démarrer immédiatement le service. Elle configure systemd afin qu’il soit lancé automatiquement lors des prochains démarrages.

Si vous souhaitez à la fois activer et démarrer immédiatement le service :

sudo systemctl enable --now nginx

Vous pouvez ensuite vérifier son état :

systemctl status nginx

Désactiver un service au démarrage

Pour empêcher le démarrage automatique d’un service :

sudo systemctl disable nom-du-service

Par exemple :

sudo systemctl disable nginx

Le service ne sera plus lancé automatiquement au prochain démarrage, mais il n’est pas arrêté immédiatement.

Pour le désactiver et l’arrêter dans la même opération :

sudo systemctl disable --now nginx

Ne pas confondre disable et mask

La commande disable empêche simplement le démarrage automatique. Le service peut toujours être lancé manuellement avec :

sudo systemctl start nginx

À l’inverse, mask bloque complètement son démarrage :

sudo systemctl mask nom-du-service

Une tentative de démarrage retourne alors une erreur indiquant que l’unité est masked.

Pour lever ce blocage :

sudo systemctl unmask nom-du-service

Utilisez mask avec prudence, car un autre service peut dépendre de l’unité que vous bloquez. Pour un simple dépannage ou pour empêcher un service de démarrer avec Linux, disable est généralement suffisant.

Vérifier pourquoi un service ne démarre pas

Lorsqu’un service refuse de démarrer, évitez de le relancer plusieurs fois sans examiner la cause de l’échec. systemctl et journalctl permettent généralement d’obtenir les premières informations nécessaires au diagnostic.

Commencez par afficher l’état du service :

systemctl status nom-du-service

Par exemple :

systemctl status nginx

Examinez particulièrement les lignes Active, Result, ExecStart et les derniers messages affichés. Un état tel que :

Active: failed (Result: exit-code)

indique que le programme a bien été lancé par systemd, mais qu’il s’est terminé avec une erreur.

Consultez ensuite les journaux complets du service :

sudo journalctl -u nom-du-service -e

Pour afficher les événements du démarrage actuel :

sudo journalctl -u nom-du-service -b

Les messages d’erreur permettent généralement de déterminer dans quelle direction poursuivre le diagnostic.

Message ou symptôme	Cause probable	Vérification
Permission denied	Droits incorrects sur un fichier, répertoire ou socket	Vérifier le propriétaire et les permissions avec ls -l ou namei -l
Address already in use	Le port utilisé par le service est déjà occupé	Identifier le processus avec ss -lntup
No such file or directory	Fichier de configuration, exécutable ou autre fichier nécessaire absent	Vérifier les chemins indiqués dans les logs
Configuration error / Syntax error	Erreur dans un fichier de configuration	Utiliser l’outil de validation fourni par l’application
Dependency failed	Un service ou une unité nécessaire est en échec	Examiner les dépendances avec systemctl list-dependencies
Failed with result ‘exit-code’	Le programme s’est terminé avec un code d’erreur	Examiner systemctl status et journalctl -u
Failed with result ‘timeout’	Le service n’a pas démarré dans le délai prévu	Rechercher un blocage, une dépendance ou une ressource inaccessible
Start request repeated too quickly	Le service plante immédiatement et systemd a cessé de tenter de le redémarrer	Corriger l’erreur initiale puis utiliser systemctl reset-failed
Out of memory / Killed process	Processus arrêté à cause d’un manque de mémoire	Vérifier la RAM, le swap et l’OOM Killer
Segmentation fault / core dumped	Le programme a planté	Examiner les journaux et utiliser coredumpctl

Vérifier si un port est déjà utilisé

Pour un serveur Web, une base de données, SSH ou tout autre service réseau, vérifiez que le port nécessaire n’est pas déjà occupé :

sudo ss -lntup

Par exemple, pour rechercher le processus utilisant le port 80 :

sudo ss -lntp | grep ':80 '

Si un autre programme écoute déjà sur ce port, le nouveau service peut échouer avec une erreur Address already in use.

Vérifier les permissions

Une erreur Permission denied peut provenir des droits d’un fichier de configuration, d’un répertoire, d’un certificat, d’un socket ou d’un fichier de log.

Commencez par vérifier les permissions :

ls -l /chemin/vers/fichier

Pour contrôler également les permissions de chaque répertoire constituant le chemin :

namei -l /chemin/vers/fichier

Cette dernière commande est particulièrement pratique lorsqu’un service possède les droits sur le fichier lui-même mais ne peut pas traverser l’un des répertoires parents.

Rechercher un manque de mémoire ou un crash

Si le processus disparaît immédiatement, recherchez une intervention de l’OOM Killer :

sudo journalctl -k | grep -i -E "oom|out of memory|killed process"

En présence d’un segfault ou d’un core dump, vérifiez également :

coredumpctl list

Puis affichez les informations du crash concerné avec :

coredumpctl info

Enfin, lorsqu’un service refuse de démarrer après une modification de sa configuration, vérifiez toujours la syntaxe avant de le redémarrer. De nombreux logiciels fournissent leur propre commande de validation, ce qui permet souvent d’identifier immédiatement la ligne ou le fichier responsable de l’erreur.

Vérifier la configuration avant de redémarrer un service

Lorsqu’un service ne fonctionne plus après la modification d’un fichier de configuration, vérifiez sa syntaxe avant de le redémarrer. De nombreux logiciels Linux disposent d’une commande permettant de valider leur configuration sans interrompre le service actuellement en cours d’exécution.

Cette précaution est particulièrement importante sur un serveur distant : une simple erreur de syntaxe dans Nginx, Apache ou SSH peut empêcher le service de redémarrer et rendre le serveur ou un site inaccessible.

Voici quelques commandes courantes :

Service	Commande de vérification
Nginx	sudo nginx -t
Apache (Debian/Ubuntu)	sudo apache2ctl configtest
Apache (RHEL/Fedora)	sudo httpd -t
PHP-FPM	sudo php-fpm -t ou la commande correspondant à la version installée
OpenSSH	sudo sshd -t
Postfix	sudo postfix check
Samba	sudo testparm

Par exemple, après avoir modifié la configuration de Nginx :

sudo nginx -t

Si la configuration est correcte, vous obtenez notamment :

syntax is ok
test is successful

Vous pouvez alors recharger la configuration sans interrompre les connexions existantes :

sudo systemctl reload nginx

Si le test retourne une erreur, ne redémarrez pas le service immédiatement. Le message indique généralement le fichier et parfois la ligne contenant l’erreur. Corrigez-la, puis relancez le test.

Pour SSH, cette précaution est encore plus importante lorsque vous administrez un serveur à distance. Après avoir modifié sshd_config, vérifiez la configuration avec :

sudo sshd -t

Si aucune erreur n’est affichée, la syntaxe est valide. Gardez toutefois votre session SSH actuelle ouverte jusqu’à ce que vous ayez confirmé qu’une nouvelle connexion fonctionne correctement.

Enfin, lorsque le logiciel le permet, préférez systemctl reload à restart pour une simple modification de configuration. reload demande au service de relire sa configuration sans l’arrêter complètement, tandis que restart provoque un arrêt puis un nouveau démarrage du service.

Réinitialiser l’état failed d’un service

Lorsqu’un service échoue à plusieurs reprises, systemd peut conserver son état failed, même après avoir corrigé la cause du problème. Dans certains cas, systemd peut également cesser temporairement de tenter de démarrer le service lorsque celui-ci plante plusieurs fois en peu de temps.

Vous pouvez vérifier les services actuellement en échec avec :

systemctl --failed

Après avoir identifié et corrigé la cause du problème, réinitialisez l’état d’échec du service avec :

sudo systemctl reset-failed nom-du-service

Par exemple, pour Nginx :

sudo systemctl reset-failed nginx

Vous pouvez ensuite tenter de démarrer à nouveau le service :

sudo systemctl start nginx

Puis vérifiez son état :

systemctl status nginx

La commande reset-failed ne répare pas le service. Elle efface simplement l’état failed enregistré par systemd ainsi que certains compteurs associés aux échecs de démarrage. Il faut donc toujours corriger l’erreur initiale avant de l’utiliser.

Cette commande est notamment utile lorsque vous rencontrez un message de ce type :

Start request repeated too quickly

ou :

Failed with result 'start-limit-hit'

Cela signifie généralement que le service a échoué plusieurs fois dans un intervalle court et que systemd a atteint sa limite de tentatives de démarrage.

Dans ce cas :

• Consultez d’abord les erreurs avec systemctl status nom-du-service.
• Examinez les journaux avec journalctl -u nom-du-service.
• Corrigez la configuration, les permissions ou le problème ayant provoqué les échecs.
• Exécutez systemctl reset-failed nom-du-service.
• Tentez à nouveau de démarrer le service.

Pour réinitialiser l’état failed de toutes les unités systemd en échec, vous pouvez utiliser :

sudo systemctl reset-failed

Cette dernière commande doit surtout être utilisée après avoir vérifié les unités concernées : effacer leur état failed sans comprendre pourquoi elles ont échoué peut masquer temporairement des problèmes qui nécessitent encore une intervention.

Vérifier les dépendances d’un service

Un service Linux peut refuser de démarrer alors que sa propre configuration est correcte parce qu’une unité dont il dépend est arrêtée ou en échec. Avec systemd, ces dépendances peuvent concerner un autre service, un point de montage, un socket, un périphérique ou une cible (target).

Pour afficher les dépendances d’un service, utilisez :

systemctl list-dependencies nom-du-service

Par exemple :

systemctl list-dependencies nginx

La commande affiche l’arborescence des unités nécessaires ou associées au fonctionnement du service.

Pour afficher également les dépendances qui ne sont pas actuellement actives :

systemctl list-dependencies --all nginx

Si une unité apparaît en échec, vérifiez son état :

systemctl status nom-de-unite

Puis consultez ses journaux :

sudo journalctl -u nom-de-unite -e

Rechercher les dépendances inverses

Il peut également être utile de déterminer quels services dépendent d’une unité donnée. Utilisez pour cela :

systemctl list-dependencies --reverse nom-du-service

Par exemple :

systemctl list-dependencies --reverse mariadb

Cela permet d’identifier les unités susceptibles d’être affectées si MariaDB est arrêté ou en échec.

Comprendre les relations entre les unités

Pour obtenir des informations plus précises sur les dépendances déclarées par un service :

systemctl show nom-du-service

Vous pouvez notamment rechercher les propriétés :

• Requires : unités nécessaires au fonctionnement du service.
• Wants : dépendances souhaitées mais généralement moins strictes.
• After et Before : ordre de démarrage entre les unités.
• BindsTo : dépendance forte à une autre unité.
• PartOf : lie certaines opérations, comme l’arrêt ou le redémarrage, à une autre unité.

Par exemple :

systemctl show nginx -p Requires -p Wants -p After

Si systemctl status affiche un message tel que Dependency failed for…, ne cherchez donc pas uniquement une erreur dans le service concerné. Identifiez d’abord l’unité en échec dont il dépend, puis corrigez celle-ci avant de tenter un nouveau démarrage.

Vérifier le fichier unit systemd

Chaque service géré par systemd repose sur un fichier unit (.service) qui décrit notamment la commande à exécuter, l’utilisateur utilisé, les dépendances, les conditions de redémarrage et l’ordre de lancement.

Lorsqu’un service ne démarre plus ou se comporte de manière inattendue, il peut être utile de vérifier le fichier unit réellement utilisé par systemd, notamment si celui-ci a été personnalisé.

Pour afficher la définition complète d’un service :

systemctl cat nom-du-service

Par exemple :

systemctl cat nginx

Cette commande est préférable à l’ouverture directe d’un fichier dans /etc/systemd/system/ ou /usr/lib/systemd/system/, car elle affiche la configuration réellement assemblée par systemd, y compris les éventuels fichiers de surcharge (drop-ins).

Vous pouvez notamment y retrouver les sections suivantes :

Section / directive	Rôle
[Unit]	Informations générales et dépendances du service
After= / Before=	Ordre de démarrage par rapport aux autres unités
Requires= / Wants=	Dépendances du service
[Service]	Paramètres d’exécution du service
ExecStart=	Commande utilisée pour démarrer le service
ExecReload=	Commande utilisée lors d’un rechargement
User= / Group=	Utilisateur et groupe sous lesquels le service s’exécute
Restart=	Comportement à adopter lorsque le processus s’arrête
WorkingDirectory=	Répertoire de travail du processus
Environment=	Variables d’environnement fournies au service
[Install]	Définit notamment comment le service est activé au démarrage

Identifier l’emplacement du fichier unit

Pour connaître précisément le fichier chargé par systemd :

systemctl show nom-du-service -p FragmentPath

Par exemple :

systemctl show nginx -p FragmentPath

Vous pouvez également afficher les éventuels fichiers de surcharge :

systemctl show nginx -p DropInPaths

Les fichiers unit fournis par les paquets sont généralement stockés dans des répertoires comme /usr/lib/systemd/system/ ou /lib/systemd/system/, tandis que les personnalisations administrateur sont généralement placées dans /etc/systemd/system/.

Vérifier les personnalisations d’un service

Un service peut fonctionner avec son fichier unit d’origine mais également avec un ou plusieurs drop-ins qui remplacent certaines directives.

La commande :

systemctl cat nom-du-service

permet de visualiser ces différentes sources dans un même affichage.

C’est particulièrement utile lorsqu’un service fonctionne différemment de sa configuration par défaut après une ancienne modification, une migration ou l’ajout d’une personnalisation systemd.

Pour modifier proprement les paramètres d’un service sans éditer directement le fichier fourni par le paquet, utilisez :

sudo systemctl edit nom-du-service

systemd crée alors une surcharge dans /etc/systemd/system/ qui ne sera pas écrasée lors d’une mise à jour du paquet.

Après toute modification d’un fichier unit ou d’un drop-in, il est nécessaire de demander à systemd de recharger ses fichiers de configuration avec systemctl daemon-reload avant de redémarrer le service.

Recharger systemd après modification d’un service

Lorsque vous modifiez un fichier unit systemd (.service) ou un fichier de surcharge (drop-in), systemd ne prend pas automatiquement en compte les changements. Il faut lui demander de relire les fichiers unit avant de redémarrer le service concerné.

Pour cela, exécutez :

sudo systemctl daemon-reload

Cette commande recharge la configuration de systemd et prend notamment en compte les modifications effectuées dans :

• /etc/systemd/system/
• /usr/lib/systemd/system/
• /lib/systemd/system/
• Les fichiers de surcharge créés avec systemctl edit

Après le rechargement, redémarrez le service concerné :

sudo systemctl restart nom-du-service

Puis vérifiez son état :

systemctl status nom-du-service

Par exemple, après avoir modifié une surcharge pour Nginx :

sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl status nginx

Ne pas confondre daemon-reload, reload et restart

Ces trois commandes ont des fonctions différentes :

Commande	Action
systemctl daemon-reload	Demande à systemd de relire les fichiers unit et leurs surcharges
systemctl reload service	Demande au service lui-même de relire sa configuration, sans l’arrêter lorsque celui-ci prend en charge cette opération
systemctl restart service	Arrête puis redémarre complètement le service

Ainsi, après avoir modifié :

/etc/systemd/system/mon-service.service

ou créé une surcharge avec :

sudo systemctl edit mon-service

utilisez :

sudo systemctl daemon-reload
sudo systemctl restart mon-service

En revanche, si vous avez uniquement modifié le fichier de configuration de l’application, par exemple nginx.conf, un daemon-reload n’est généralement pas nécessaire. Après avoir vérifié la syntaxe, vous pouvez simplement recharger Nginx :

sudo nginx -t
sudo systemctl reload nginx

Retenez donc que daemon-reload concerne la configuration de systemd, tandis que reload concerne la configuration du service ou de l’application.

Tableau des commandes systemctl pour dépanner un service

Le tableau suivant récapitule les principales commandes systemctl à connaître pour vérifier, diagnostiquer et réparer un service géré par systemd.

Commande	Description
systemctl list-units --type=service	Lister les services actuellement chargés
systemctl list-unit-files --type=service	Lister tous les fichiers de services installés et leur état d’activation
systemctl --failed	Afficher les unités actuellement en échec
systemctl status service	Afficher l’état détaillé d’un service et ses derniers messages
systemctl is-active service	Vérifier rapidement si un service est actif
systemctl is-enabled service	Vérifier si un service est activé au démarrage
systemctl start service	Démarrer un service
systemctl stop service	Arrêter un service
systemctl restart service	Arrêter puis redémarrer un service
systemctl reload service	Recharger la configuration d’un service sans l’arrêter, lorsque cette fonction est prise en charge
systemctl enable service	Activer le démarrage automatique d’un service
systemctl enable --now service	Activer un service au démarrage et le démarrer immédiatement
systemctl disable service	Désactiver le démarrage automatique d’un service
systemctl disable --now service	Désactiver le service au démarrage et l’arrêter immédiatement
systemctl mask service	Bloquer complètement le démarrage d’un service
systemctl unmask service	Lever le blocage appliqué avec mask
systemctl reset-failed service	Effacer l’état failed et les compteurs d’échec d’un service
systemctl list-dependencies service	Afficher les dépendances d’un service
systemctl list-dependencies --reverse service	Afficher les unités qui dépendent du service
systemctl cat service	Afficher le fichier unit et les éventuels fichiers de surcharge (drop-ins)
systemctl show service	Afficher toutes les propriétés systemd d’un service
systemctl edit service	Créer ou modifier proprement une surcharge du fichier unit
systemctl daemon-reload	Demander à systemd de relire les fichiers unit après une modification

Pour un diagnostic rapide d’un service qui ne démarre plus, commencez généralement par ces trois commandes :

systemctl status nom-du-service
sudo journalctl -u nom-du-service -e
systemctl list-dependencies nom-du-service

Si le service a échoué plusieurs fois et que systemd refuse désormais de le relancer avec un message comme Start request repeated too quickly, corrigez d’abord l’erreur puis utilisez :

sudo systemctl reset-failed nom-du-service
sudo systemctl start nom-du-service

Enfin, n’oubliez pas que systemctl et journalctl sont complémentaires : systemctl permet surtout de connaître et modifier l’état du service, tandis que journalctl permet d’analyser ses journaux afin de déterminer pourquoi il a échoué.