Top 5 des commandes systemctl pour booster votre productivité sous Linux
Cinq commandes pratiques de systemctl pour vérifier, contrôler, activer, lister et recharger les services Linux.
Top 5 des commandes systemctl pour booster votre productivité sous Linux
Les systèmes Linux dépendent de services en arrière-plan pour presque tout : accès SSH, réseau, journalisation, serveurs web, bases de données, tâches planifiées et écrans de connexion du bureau. Lorsque l'un de ces services se comporte mal, systemctl est généralement le premier outil que vous utilisez.
systemctl est l'interface en ligne de commande principale pour systemd, le gestionnaire de services utilisé par de nombreuses distributions Linux grand public. Vous n'avez pas besoin de mémoriser chaque sous-commande pour être efficace. Dans le travail quotidien, un petit ensemble de commandes couvre la plupart des vérifications de services, redémarrages, modifications de configuration de démarrage et mises à jour de fichiers d'unité.
Comprendre Systemd et systemctl
Avant de plonger dans les commandes, examinons brièvement systemd et systemctl. systemd est responsable de l'initialisation du système, de la gestion des services, du traitement des processus, etc. Il remplace les anciens systèmes d'initialisation comme SysVinit et Upstart, offrant des temps de démarrage plus rapides, un démarrage parallèle des services et une gestion des dépendances plus robuste. systemctl est votre fenêtre sur le monde systemd, vous permettant de contrôler et d'interroger l'état des services, des unités et des cibles.
Une "unité" dans la terminologie systemd fait référence à toute ressource que systemd sait gérer. Les services (.service), les points de montage (.mount), les périphériques (.device), les sockets (.socket) et les cibles (.target) sont des types d'unités courants. Pour les besoins de cet article, nous nous concentrerons principalement sur les unités de service, qui représentent les processus démons gérés par systemd.
Les 5 meilleures commandes systemctl pour une productivité accrue
Voici cinq commandes systemctl qui amélioreront considérablement votre capacité à gérer et surveiller les services de votre système Linux.
1. systemctl status [NOM_DU_SERVICE]
Objectif : Cette commande est votre première ligne de défense pour surveiller la santé et l'activité de tout service. Elle fournit des informations détaillées, notamment si un service est en cours d'exécution, récemment arrêté, activé pour le démarrage automatique, et même les dernières entrées de journal.
Pourquoi c'est productif : Diagnostiquer rapidement les problèmes, confirmer le démarrage/l'arrêt du service et obtenir un aperçu de l'état d'un service sans fouiller manuellement dans les fichiers journaux.
Exemple :
Pour vérifier l'état du serveur web Apache (httpd.service sur certaines distributions, apache2.service sur d'autres comme Debian/Ubuntu) :
systemctl status apache2.service
Interprétation de la sortie (exemple) :
● apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2023-10-26 10:00:00 UTC; 1min 2s ago
Docs: https://httpd.apache.org/docs/2.4/
Process: 1234 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
Main PID: 1239 (apache2)
Tasks: 6 (limit: 4639)
Memory: 21.6M
CPU: 184ms
CGroup: /system.slice/apache2.service
├─1239 /usr/sbin/apache2 -k start
├─1240 /usr/sbin/apache2 -k start
└─1241 /usr/sbin/apache2 -k start
Oct 26 10:00:00 servername systemd[1]: Starting The Apache HTTP Server...
Oct 26 10:00:00 servername systemd[1]: Started The Apache HTTP Server.
Cette sortie vous indique :
Loaded: Où se trouve le fichier d'unité et s'il est activé pour démarrer au démarrage.Active: Statut actuel (par exemple,active (running),inactive (dead),failed).- Entrées de journal récentes de
journalctl.
Astuce : Appuyez sur q pour quitter la vue d'état.
Deux détails dans status sont faciles à manquer. Premièrement, Loaded: vous indique si le fichier d'unité existe et s'il est activé pour le démarrage. Un service peut être active (running) et toujours disabled ; cela signifie qu'il a été démarré manuellement ou par une autre dépendance, mais il ne démarrera pas nécessairement au prochain démarrage. Deuxièmement, les dernières lignes de journal ne sont qu'un aperçu. Si l'erreur utile a défilé, utilisez journalctl -u apache2.service au lieu d'essayer de tout extraire de status.
Pour les scripts et les vérifications de surveillance, préférez les commandes adaptées aux machines :
systemctl is-active --quiet apache2.service
systemctl is-enabled apache2.service
is-active --quiet se termine avec le code de statut 0 lorsque le service est actif. Cela le rend utile dans une petite vérification de santé :
if ! systemctl is-active --quiet apache2.service; then
echo "apache2 n'est pas en cours d'exécution"
fi
2. systemctl start|stop|restart [NOM_DU_SERVICE]
Objectif : Ces commandes vous donnent un contrôle direct sur le cycle de vie d'exécution d'un service.
start: Démarre un service.stop: Arrête un service en cours d'exécution.restart: Arrête puis démarre un service (utile pour appliquer des modifications de configuration).
Pourquoi c'est productif : Essentiel pour la maintenance de base des services, le dépannage et l'application des mises à jour de configuration. Au lieu de redémarrer tout le système, vous pouvez contrôler précisément des services individuels.
Exemples : Pour arrêter le serveur web Apache :
sudo systemctl stop apache2.service
Pour le redémarrer :
sudo systemctl start apache2.service
Pour le redémarrer après avoir modifié ses fichiers de configuration :
sudo systemctl restart apache2.service
Avertissement : Ces commandes nécessitent généralement les privilèges sudo car elles affectent les services à l'échelle du système. Assurez-vous toujours de cibler le bon service pour éviter des perturbations involontaires.
Utilisez restart avec précaution sur les services de production. Il arrête le processus et le redémarre, ce qui peut interrompre les connexions actives à moins que l'application ne gère bien l'arrêt gracieux. Si l'unité prend en charge les rechargements, c'est souvent mieux après un changement de configuration uniquement :
sudo systemctl reload nginx.service
Tous les services ne prennent pas en charge le rechargement. Vérifiez la définition de l'unité avant de supposer qu'elle le fait :
systemctl cat nginx.service | grep ExecReload
S'il n'y a pas de ExecReload=, systemctl reload échouera généralement. Dans ce cas, vous redémarrez le service ou utilisez la commande de rechargement spécifique à l'application.
3. systemctl enable|disable [NOM_DU_SERVICE]
Objectif : Ces commandes gèrent si un service démarrera automatiquement au démarrage de votre système.
enable: Configure un service pour qu'il démarre automatiquement au démarrage. Cela crée un lien symbolique du répertoire ciblesystemdapproprié vers le fichier d'unité du service.disable: Empêche un service de démarrer automatiquement au démarrage en supprimant le lien symbolique.
Pourquoi c'est productif : Contrôler l'utilisation des ressources, optimiser les temps de démarrage et garantir que les services critiques sont toujours disponibles (ou empêcher les services inutiles de s'exécuter).
Exemples : Pour garantir qu'Apache démarre à chaque démarrage de votre système :
sudo systemctl enable apache2.service
Pour empêcher un service inutile (par exemple, cups.service si vous n'utilisez pas l'impression) de démarrer au démarrage :
sudo systemctl disable cups.service
Meilleure pratique : Désactivez les services dont vous n'avez pas besoin, mais vérifiez d'abord ce qui en dépend. Sur un ordinateur portable, désactiver le Bluetooth ou l'impression peut être inoffensif. Sur un serveur, désactiver un service réseau, de stockage ou d'authentification sans vérifier les dépendances peut vous bloquer ou casser le démarrage.
N'oubliez pas que enable et disable n'affectent que le comportement au démarrage. Ils ne démarrent ni n'arrêtent le service immédiatement. Si vous souhaitez les deux actions ensemble, utilisez :
sudo systemctl enable --now apache2.service
sudo systemctl disable --now cups.service
--now est utile car il supprime une erreur courante : activer un service et supposer qu'il est déjà en cours d'exécution.
4. systemctl list-unit-files --type=service
Objectif : Cette commande liste tous les fichiers d'unité de service systemd connus de votre système, ainsi que leur statut enabled ou disabled. C'est extrêmement utile pour obtenir un aperçu des services configurés sur votre système.
Pourquoi c'est productif : Vous aide à découvrir les services installés, à identifier ceux qui sont inutiles et à auditer la configuration de démarrage de votre système. C'est un outil puissant pour la reconnaissance et le nettoyage du système.
Exemple :
systemctl list-unit-files --type=service
Sortie partielle (exemple) :
UNIT FILE STATE
acpid.service enabled
aptd-auto-update.service static
apt-daily.service static
apache2.service enabled
avahi-daemon.service enabled
bluetooth.service enabled
cups.service enabled
... (beaucoup d'autres services)
78 unit files listed.
Astuce : La colonne STATE indique si le service est configuré pour démarrer au démarrage (enabled), explicitement empêché (disabled), ou static (ne peut pas être activé/désactivé via systemctl enable/disable directement, souvent des dépendances ou des unités systemd internes).
Filtrage : Vous pouvez rediriger la sortie vers grep pour trouver des services spécifiques :
systemctl list-unit-files --type=service | grep ssh
Lorsque vous vous souciez des services en cours d'exécution plutôt que des fichiers d'unité installés, utilisez list-units à la place :
systemctl list-units --type=service --state=running
systemctl list-units --type=service --state=failed
Cette distinction est importante lors du nettoyage. list-unit-files vous indique ce que systemd sait démarrer. list-units vous indique ce que systemd a chargé dans son état d'exécution actuel.
5. systemctl daemon-reload
Objectif : Après avoir modifié un fichier d'unité systemd (par exemple, en créant un nouveau fichier de service dans /etc/systemd/system/ ou en modifiant un existant), systemd ne reconnaît pas automatiquement ces modifications. systemctl daemon-reload demande à systemd de rescanner tous les fichiers d'unité et de recharger leurs configurations.
Pourquoi c'est productif : Évite la nécessité d'un redémarrage complet du système simplement pour appliquer les modifications de configuration aux services. C'est crucial pour les développeurs et les administrateurs qui modifient fréquemment les configurations de service.
Exemple :
Supposons que vous ayez créé un nouveau fichier d'unité de service pour votre application personnalisée, mywebapp.service.
Créez
/etc/systemd/system/mywebapp.service.Rechargez la configuration de
systemd:
sudo systemctl daemon-reload ```
Maintenant,
systemdconnaîtmywebapp.service, et vous pouvez lestart,enable,status:
sudo systemctl start mywebapp.service sudo systemctl enable mywebapp.service systemctl status mywebapp.service ```
Important : daemon-reload ne recharge que les définitions d'unité. Si un service est déjà en cours d'exécution, les modifications apportées à son fichier d'unité ne prendront effet qu'après le redémarrage du service (systemctl restart [NOM_DU_SERVICE]).
Un flux de travail quotidien simple
Lorsque j'arrive sur un serveur inconnu, je travaille généralement dans cet ordre :
systemctl status sshd.service
systemctl list-units --type=service --state=failed
systemctl list-unit-files --type=service | grep enabled
systemctl get-default
Cela vous donne une image rapide de l'hôte : si l'accès à distance est sain, si des unités ont échoué, ce qui est configuré pour démarrer au démarrage et si la machine est censée démarrer dans une cible de type serveur ou graphique.
Pour un changement de service, le flux de travail est tout aussi court :
sudo systemctl edit myapp.service
sudo systemctl daemon-reload
sudo systemctl restart myapp.service
systemctl status myapp.service
journalctl -u myapp.service -n 50 --no-pager
Cette séquence maintient le changement visible, recharge le cache d'unité de systemd, redémarre uniquement le service concerné et vérifie les journaux avant de vous éloigner. Cela évite beaucoup de redémarrages évitables et de conjectures.
Quelques variations utiles
Une fois que les commandes de base vous semblent naturelles, ajoutez quelques variations qui font gagner du temps sans modifier le flux de travail de base.
Pour voir uniquement les unités en échec :
systemctl --failed
C'est l'une des vérifications les plus rapides après un redémarrage. Si une mise à jour de paquet a modifié une unité, un montage a expiré ou un service personnalisé a planté pendant le démarrage, il apparaîtra souvent ici avant qu'un utilisateur ne signale un problème.
Pour inspecter le contenu exact de l'unité que systemd a chargée :
systemctl cat docker.service
Cela est important car le fichier dont vous vous souvenez avoir modifié peut ne pas être toute l'histoire. Une unité de paquet dans /usr/lib/systemd/system/ peut être modifiée par un ou plusieurs drop-ins sous /etc/systemd/system/docker.service.d/. systemctl cat montre la vue combinée afin que vous ne déboguiez pas le mauvais fichier.
Pour voir pourquoi un service démarre au démarrage :
systemctl list-dependencies multi-user.target
systemctl list-dependencies graphical.target
Cela aide lorsque quelqu'un demande : "Pourquoi cela tourne-t-il ?" Un service peut être activé directement, tiré par une cible, activé par socket ou démarré par une autre unité. Le comportement au démarrage est souvent une question de dépendance, pas seulement une question d'activé ou désactivé.
Pour vérifier les journaux récents sans ouvrir un pagineur :
journalctl -u sshd.service -n 50 --no-pager
systemctl status donne un petit aperçu des journaux, mais journalctl vous donne le contrôle sur la plage de temps, le démarrage, le nombre de lignes et le format de sortie. Par exemple :
journalctl -u sshd.service --since "today" --no-pager
journalctl -u sshd.service -b -1 --no-pager
La deuxième commande vérifie le démarrage précédent, ce qui est utile après un crash ou un redémarrage inattendu.
Il n'y a pas de prix pour utiliser la commande systemctl la plus longue. La productivité vient de la connaissance de la petite commande qui répond à la question actuelle : est-ce en cours d'exécution, devrait-il démarrer au démarrage, qu'est-ce qui a échoué, qu'est-ce qui a changé, et systemd a-t-il rechargé la définition que j'ai modifiée ?
Une dernière habitude aide sur les machines partagées : laissez une trace de ce que vous avez modifié. Si vous désactivez un service, notez la raison dans votre ticket, runbook ou journal des modifications. Six mois plus tard, quelqu'un pourrait voir disabled et supposer que c'est une erreur. La commande est simple :
sudo systemctl disable --now old-worker.service
Le contexte opérationnel est la partie que les gens perdent. A-t-il été remplacé par une minuterie ? Provoquait-il des tâches en double ? N'était-il nécessaire que pendant la migration ? systemctl peut montrer l'état, mais il ne peut pas expliquer l'intention. Une courte note à côté du changement empêche la personne suivante d'annuler une bonne décision.