Services Linux : les commandes systemctl à connaître avant de redémarrer au hasard

Avant de redémarrer un service Linux, je préfère toujours regarder ce qui tourne vraiment. Sur une machine avec systemd, systemctl donne déjà presque tout ce qu’il faut : services actifs, services en échec, démarrage automatique, état détaillé et derniers messages utiles.

C’est particulièrement vrai sur un serveur. Relancer nginx, ssh, mariadb ou un service métier sans vérifier son état peut couper une session, interrompre un site, ou masquer une erreur de configuration. Voici les commandes à connaître pour lister les services Linux proprement, filtrer ce qui compte, puis décider si un redémarrage est vraiment nécessaire.

Lister les services actifs avec systemctl

La commande la plus directe consiste à afficher les unités de type service actuellement chargées :

systemctl list-units --type=service

Vous obtenez une liste avec plusieurs colonnes. Les plus importantes sont LOAD, ACTIVE, SUB et DESCRIPTION. Dans la pratique, je regarde surtout ACTIVE et SUB : un service peut être chargé, mais arrêté, en erreur, ou simplement terminé parce que c’est son comportement normal.

Pour ne voir que les services en cours d’exécution :

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

Pour afficher les services arrêtés :

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

Ne paniquez pas si vous voyez des services en exited. Certains lancent une action courte puis s’arrêtent normalement. Il faut regarder le service concerné avant de conclure qu’il y a un problème.

Voir les services en échec

Quand une machine se comporte mal, commencez par cette commande :

systemctl --failed

Elle affiche les unités que systemd considère en échec. C’est plus utile qu’un redémarrage à l’aveugle, parce que vous voyez immédiatement le nom exact du service à inspecter.

Exemple :

systemctl status ssh

ou, selon la distribution :

systemctl status sshd

La sortie indique l’état du service, le fichier d’unité utilisé, le PID principal si le service tourne, et les dernières lignes de logs. Si vous devez diagnostiquer un démarrage raté, ces quelques lignes donnent souvent la première piste.

Savoir si un service démarre automatiquement

Un service peut être actif maintenant sans être activé au démarrage. L’inverse est aussi possible : un service peut être activé, mais arrêté parce qu’il a échoué ou parce qu’il n’a pas encore été lancé.

Pour lister les fichiers d’unité et leur état au démarrage :

systemctl list-unit-files --type=service

Les états les plus courants sont :

enabled : le service est prévu pour démarrer automatiquement ;
disabled : il ne démarre pas automatiquement ;
static : il ne s’active pas directement, mais peut être appelé par une autre unité ;
masked : le service est volontairement bloqué.

Pour vérifier un service précis :

systemctl is-enabled nginx
systemctl is-active nginx

La première commande répond sur le démarrage automatique. La seconde répond sur l’état actuel. Les deux informations ne remplacent pas un systemctl status, mais elles sont pratiques dans un script de contrôle ou une checklist rapide.

Filtrer la liste sans se noyer

Sur un serveur un peu chargé, la liste complète devient vite longue. Vous pouvez filtrer avec grep quand vous cherchez une famille de services :

systemctl list-units --type=service | grep ssh

Pour afficher seulement les services actifs sans pager :

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

Et si vous voulez une sortie plus lisible dans un ticket ou un diagnostic court :

systemctl list-units --type=service --state=failed --no-pager

Sur un serveur distant, j’ajoute souvent --no-pager. Ça évite de rester coincé dans l’affichage interactif, surtout quand vous travaillez vite en SSH.

Lire les logs avant de redémarrer

Si un service est en erreur, ne commencez pas par restart. Regardez d’abord les journaux :

journalctl -u nginx -n 50 --no-pager

Pour suivre les logs en direct :

journalctl -u nginx -f

C’est souvent là que vous voyez une erreur de port déjà utilisé, un fichier de configuration invalide, une permission incorrecte ou une dépendance absente. Si vous débutez avec les journaux systemd, j’ai aussi détaillé comment lire les logs du dernier démarrage Linux avec journalctl.

Redémarrer seulement après les bonnes vérifications

Une fois le service identifié, vérifiez sa configuration quand l’outil le permet. Pour Nginx, par exemple :

nginx -t

Pour SSH, soyez encore plus prudent. Si vous redémarrez le mauvais service ou si la configuration est invalide, vous pouvez perdre l’accès distant. Gardez une session ouverte, vérifiez le pare-feu, puis utilisez plutôt reload quand c’est suffisant.

sudo systemctl reload ssh
sudo systemctl restart ssh

La commande reload demande au service de relire sa configuration sans l’arrêter complètement, si le service le supporte. restart coupe puis relance le service. Ce n’est pas le même niveau de risque.

Si vous avez modifié un fichier d’unité systemd, pensez aussi à la différence avec daemon-reload. J’ai expliqué ce cas à part dans l’article Systemctl daemon-reload : quand faut-il vraiment l’utiliser sous Linux ?.

La mini-checklist avant de toucher à un service

Listez les services concernés avec systemctl list-units --type=service.
Vérifiez les erreurs avec systemctl --failed.
Lisez l’état précis avec systemctl status nom-du-service.
Regardez les logs avec journalctl -u nom-du-service.
Testez la configuration si le service propose une commande de validation.
Préférez reload à restart quand c’est supporté et suffisant.

La documentation de systemctl détaille toutes les options, mais pour un usage quotidien, ces commandes couvrent déjà la majorité des diagnostics. Mon conseil : si vous ne savez pas pourquoi vous redémarrez un service, ne le redémarrez pas encore. Listez, lisez les logs, puis agissez.