systemctl : toutes les façons de lister les services Linux

La commande à connaître : systemctl list-units --type=service

Sur toute distribution qui utilise systemd — Ubuntu depuis la 15.04, Debian depuis la 8, RHEL et CentOS depuis la 7, ainsi que Fedora, Arch et openSUSE — chaque service est une unité systemd, et systemctl est l'outil qui les liste :

systemctl list-units --type=service

Par défaut, la commande affiche toutes les unités de service que systemd a actuellement en mémoire : les services actifs, ceux qui ont des tâches en attente ou ceux qui ont échoué. Elle n'affiche pas les services installés mais jamais démarrés. Quand la sortie dépasse la hauteur du terminal, systemctl la redirige vers un pager (less) — appuyez sur q pour quitter, ou ajoutez --no-pager pour écrire directement sur la sortie standard.

Chaque ligne comporte cinq colonnes :

• UNIT — le nom de l'unité, par exemple ssh.service. C'est le nom exact à passer à systemctl status, start et stop.
• LOAD — indique si le fichier d'unité a été analysé correctement : loaded, not-found, bad-setting, error ou masked.
• ACTIVE — l'état de haut niveau : active, inactive, activating, deactivating ou failed.
• SUB — l'état de bas niveau, propre au type d'unité : un service peut être running, exited, dead, etc.
• DESCRIPTION — le texte lisible par un humain, issu du fichier d'unité.

Lisez le couple ACTIVE/SUB ensemble : active (running) signifie qu'un processus est vivant en ce moment, tandis que active (exited) signifie qu'un service oneshot s'est exécuté avec succès puis terminé — normal pour des tâches d'initialisation, ce n'est pas un problème à corriger.

Filtrer : en cours, en échec, ou tout

L'option --state= filtre sur n'importe quelle valeur de LOAD, ACTIVE ou SUB et accepte des listes séparées par des virgules :

# Only services with a live process
systemctl list-units --type=service --state=running

# Everything loaded, including stopped and dead services
systemctl list-units --type=service --all

# Only failures
systemctl list-units --type=service --state=failed

# Combine states
systemctl list-units --type=service --state=running,exited

systemctl --failed est un raccourci intégré pour le filtre des unités en échec, et mérite d'être lancé par réflexe sur toute machine où vous vous connectez. Pour une sortie exploitable par une machine, --no-legend supprime l'en-tête et les lignes de résumé et --plain retire les puces, ce qui garde des colonnes stables pour awk ou cut. Pour chercher par nom, passez par grep : systemctl list-units --type=service --all --no-pager | grep ssh.

Ce qui démarre au boot : systemctl list-unit-files

list-units répond à « qu'est-ce qui tourne maintenant ? ». Pour répondre à « qu'est-ce qui démarrera au boot ? », listez plutôt les fichiers d'unités installés sur le disque :

systemctl list-unit-files --type=service
systemctl list-unit-files --type=service --state=enabled

Ici, la colonne STATE décrit la configuration de démarrage, pas l'état d'exécution :

• enabled — démarre automatiquement au boot (ou sur son déclencheur, pour les services activés par socket ou par timer).
• disabled — installé, mais rien ne le démarre automatiquement.
• static — n'a pas de section [Install] ; il ne s'exécute qu'en tant que dépendance d'une autre unité et ne peut pas être activé directement.
• masked — lié symboliquement vers /dev/null ; systemd refuse tout simplement de le démarrer.
• generated — créé à l'exécution par un générateur, typiquement depuis un ancien script d'init.

Les versions récentes de systemd affichent aussi une colonne de preset (VENDOR PRESET ou PRESET selon la version) indiquant ce que serait le réglage par défaut de la distribution. Le piège à éviter : activé ne veut pas dire en cours d'exécution, et désactivé ne veut pas dire arrêté. Un service peut être désactivé tout en tournant parce que quelqu'un l'a démarré à la main, ou activé tout en étant mort parce qu'il a planté. Quand cela compte, croisez les deux listes.

Un service à la fois : status, is-active, is-enabled

Dès qu'un service attire votre attention, zoomez :

systemctl status nginx
systemctl is-active nginx    # prints: active | inactive | failed
systemctl is-enabled nginx   # prints: enabled | disabled | static | masked
systemctl is-failed nginx

status donne le tableau complet : état ACTIVE/SUB, PID principal, durée de fonctionnement, mémoire utilisée, arborescence des processus du cgroup et les dix dernières lignes du journal. Quand dix lignes ne suffisent pas, allez directement au journal avec journalctl -xeu nginx (-u filtre par unité, -e saute à la fin, -x ajoute des explications).

Les commandes is-* sont faites pour le scripting : elles affichent un seul mot et positionnent le code de sortie en conséquence — is-active sort avec 0 uniquement si l'unité est active, et is-enabled sort avec un code non nul pour les unités désactivées ou masquées. Ajoutez --quiet pour supprimer l'affichage et ne garder que le code de sortie.

Toutes les commandes de listage ci-dessus fonctionnent en tant qu'utilisateur non privilégié. Gérer réellement les services — start, stop, enable, disable — exige les droits root : vous voudrez donc comprendre comment fonctionnent sudo et le changement d'utilisateur sur Ubuntu avant d'aller plus loin que la lecture de l'état. Notez aussi que les unités au niveau utilisateur vivent dans un gestionnaire séparé : systemctl --user list-units --type=service liste les services de votre propre session, ce qui explique pourquoi certains services semblent « absents » de la liste système.

Aide-mémoire : les listages que vous utiliserez vraiment

Cas d'usage réels

1. Trouver le service qui échoue en boucle

systemctl --failed
systemctl status myapp.service --no-pager -l
journalctl -xeu myapp.service
systemctl reset-failed myapp.service

Commencez large avec --failed, puis lisez la sortie de status pour le code de sortie et les dernières lignes de log, puis creusez dans le journal pour la trace complète. Une fois la cause corrigée et le service relancé, reset-failed efface l'entrée en échec obsolète pour que votre prochain contrôle de santé reparte propre.

2. Auditer ce qui démarrera au prochain boot

systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'
systemd-analyze blame

La première commande vous donne une liste nette de tout ce qui démarrera automatiquement — utile avant de durcir un serveur ou pour retrouver quelque chose installé il y a des mois puis oublié. systemd-analyze blame montre ensuite combien de temps chaque unité a pris lors du dernier démarrage, et c'est là que les services lents ressortent immédiatement.

3. Commandes d'une ligne pour les scripts et la supervision

systemctl is-active --quiet nginx && echo up || echo down
systemctl list-units --type=service --state=running --no-legend --plain | awk '{print $1}'
systemctl show -p ActiveState,SubState nginx
systemctl list-units --type=service -o json   # systemd 246 or newer

show -p affiche des paires Key=Value dont le format ne change jamais d'une version à l'autre, et la sortie JSON alimente directement jq. Si vous relancez sans cesse les mêmes vérifications à chaque connexion, encapsulez-les dans un petit script — notre guide des fichiers .sh et du scripting shell explique comment transformer exactement ce genre d'extrait en outil réutilisable.

Pas de systemd ? service --status-all et OpenRC

Avant de supposer que systemctl existe, vérifiez ce que la machine exécute réellement — contrôler l'OS et sa version en ligne de commande prend dix secondes et vous dit si vous êtes bien sur une distribution systemd. Si systemctl est absent, vous êtes sur SysV init ou OpenRC :

service --status-all

Sur Debian et Ubuntu, cette commande parcourt /etc/init.d et affiche [ + ] pour un service en cours, [ - ] pour un service arrêté et [ ? ] pour les scripts sans commande status. Elle fonctionne encore sur les distributions systemd via une couche de compatibilité, mais elle ne voit que les scripts d'init : préférez donc systemctl dans ce cas. Sur Alpine et Gentoo, OpenRC est le système d'init : rc-status liste les services du runlevel courant et rc-update show liste ce que chaque runlevel démarre.

Tout ce qui précède suppose que vous disposez d'une machine Linux où vous êtes root et pouvez démarrer, casser et réparer des services librement. S'il vous en faut une pour vous entraîner — ou une machine propre pour héberger de vraies charges de travail — un VPS Linux avec accès root complet de rdp.monster offre CPU et RAM dédiés, une bande passante illimitée (fair-use), aucun KYC, et il est livré environ 10 secondes après confirmation du paiement : vous pouvez donc lancer systemctl list-units sur votre propre serveur en moins d'une minute.

Foire aux questions

Pourquoi un service affiche-t-il active (exited) au lieu de active (running) ?

C'est un service oneshot qui s'est exécuté avec succès puis terminé — ce n'est pas une erreur.

Les services avec Type=oneshot (ou RemainAfterExit=yes) exécutent une tâche une seule fois — montage, configuration du pare-feu, nettoyage — puis se terminent. systemd rapporte alors active (exited) : l'unité a réussi et est considérée comme « active », mais aucun processus ne subsiste. Seuls les démons comme nginx ou sshd affichent active (running). Si un service que vous attendez comme démon affiche exited, inspectez son fichier d'unité avec systemctl cat nom.service pour voir comment il est déclaré.

Que signifient les points de couleur dans la sortie de systemctl ?

Vert signifie actif, blanc inactif, et rouge en échec ou en erreur.

La puce placée devant un nom d'unité dans systemctl status et systemctl list-units est un indicateur d'état rapide : vert pour actif, blanc pour inactif ou en cours d'arrêt, et rouge pour les états en échec ou en erreur. Les lignes en échec sont aussi surlignées en rouge dans les listes, ce qui rend systemctl --failed très lisible. Dans les scripts ou les logs où les codes de couleur gênent, ajoutez --plain ou redirigez la sortie, et les décorations disparaîtront.

Existe-t-il un équivalent systemctl de chkconfig --list ?

Oui — systemctl list-unit-files --type=service remplace chkconfig --list.

Sur RHEL et CentOS 7 ou plus récent, chkconfig --list est remplacé par systemctl list-unit-files --type=service, qui affiche chaque service installé et s'il est enabled, disabled, static ou masked. Pour un seul service, systemctl is-enabled nom remplace chkconfig nom, et systemctl enable nom remplace chkconfig nom on. L'ancienne commande peut encore exister comme couche de compatibilité, mais elle ne couvre que les anciens scripts SysV.

Comment empêcher un service de démarrer au boot ?

Utilisez systemctl disable pour le retirer du démarrage, ou mask pour le bloquer totalement.

Lancez sudo systemctl disable nom pour supprimer le lien symbolique de démarrage ; ajoutez --now pour l'arrêter aussi immédiatement. Un service désactivé peut encore être démarré à la main ou tiré comme dépendance d'une autre unité. Si vous voulez qu'il ne démarre jamais, utilisez sudo systemctl mask nom, qui lie l'unité à /dev/null de sorte que toute tentative de démarrage échoue. Vous pourrez revenir en arrière avec systemctl unmask. Vérifiez le résultat avec systemctl is-enabled nom.