Gestion des services avec Systemd : le guide complet de Systemctl

Dans les systèmes Linux modernes , systemd et son outil systemctl sont essentiels à la gestion et au démarrage des services . Si vous travaillez quotidiennement avec des serveurs ou des postes de travail, la maîtrise de ces utilitaires vous permettra de démarrer, d'arrêter, de déboguer et d'automatiser facilement les services.

Ce guide vous offre une vue d'ensemble complète et pratique de la gestion des services avec systemd : des opérations de base (démarrage, arrêt, activation) aux options avancées telles que l'isolation des cibles, la modification des unités avec des substitutions, l'analyse des processus de démarrage et même son activation dans WSL. La compatibilité entre les distributions et les autres systèmes d'initialisation est également abordée, vous évitant ainsi toute mauvaise surprise.

Qu'est-ce que systemd et comment organise-t-il le système ?

En résumé, systemd est le système d'initialisation et le gestionnaire de services qui s'exécute avec le PID 1 et coordonne le démarrage et le cycle de vie des processus utilisateur. Au sein de son écosystème, les composants clés sont les « unités », qui représentent des ressources gérables telles que les services, les sockets, les points de montage, les périphériques ou les cibles.

Les unités sont décrites avec fichiers unitaires avec suffixes qui indiquent leur type : .service (services), .socket (sockets), .target (états système), entre autres. Ces fichiers se trouvent dans des chemins tels que /lib/systemd/system y /etc/systemd/system, et peut être visualisé, répertorié et modifié avec systemctl.

Outre systemctl, l'écosystème est complété par des utilitaires tels que journalctl (journaux), loginctl (sessions), hostnamectl , localectl , timedatectl et des outils d'inspection comme systemd-cgls . L'ensemble contribue à une administration plus fine et plus centralisée.

Si vous devez modifier les paramètres globaux par défaut, vous pouvez les modifier /etc/systemd/system.conf (par exemple, DefaultTimeoutStartSec) et ainsi de suite remplacer les valeurs de compilation dans tout le système sans toucher unité par unité.

Démarrage, arrêt, redémarrage et rechargement des services

La vie quotidienne commence par l’essentiel : démarrer et arrêter les services. Les usages sudo systemctl start nombre.service pour commencer et sudo systemctl stop nombre.service pour arrêter. Le suffixe .service est facultatif ; systemd est malin et le déduit généralement. Dans les environnements Fenêtres là commandes équivalents pour Contrôler les processus et les services sous Windows.

Lorsque vous effectuez des modifications de configuration, cela touche généralement redémarrer avec sudo systemctl restart nombre.serviceSi le service prend en charge la recharge à chaud, vous évitez une panne avec sudo systemctl reloadSi vous ne savez pas si vous devez recharger ou non, tirez recharger ou redémarrer et prêt.

Notez que certains démons sont destinés à réapparaître après un arrêt en raison de sa propre politique de redémarrage. Ceci est courant dans les infrastructures telles que systemd-networkd, alors ne soyez pas surpris s'il se relève.

Soyez prudent avec les variantes entre les distributions : sur Ubuntu Desktop, il est courant de travailler avec Gestionnaire de réseau, ainsi des commandes telles que l'état du réseau pourraient être interrogées dans NetworkManager.service au lieu de systemd-networkd.service.

Activer, désactiver et vérifier l'état

Pour un service démarrer automatiquement avec le système, utilisez sudo systemctl enable nombre.service. Cela crée des liens symboliques depuis votre fichier d'unité vers les chemins .../target.wants de la cible correspondante. Sous Windows, il existe des consignes sur les services à ne pas toucher, par exemple Services Windows 11 que vous ne devriez pas désactiver.

Si vous ne le souhaitez pas au démarrage, désactivez-le avec sudo systemctl disableN'oubliez pas que l'activation/la désactivation ne démarre ni n'arrête le service dans la session en cours ; vous combinerez l'activation/la désactivation avec le démarrage/l'arrêt selon le cas.

Pour vérifier l'état en détail, état systemctl Il vous indique la charge, l'activité, le PID, le groupe de contrôle et les dernières lignes de journal de l'unité. Pour un avis rapide : systemctl is-active (en cours d'exécution ou non), systemctl is-enabled (activé ou désactivé) et systemctl is-failed (échec, inactif, inconnu) avec des codes de sortie pratiques pour les scripts.

Explorer le système : list-units et list-unit-files

Pour obtenir une vue d'ensemble, la commande `systemctl list-units` affiche les unités actives. Les colonnes UNIT, LOAD, ACTIVE, SUB et DESCRIPTION vous permettent de visualiser rapidement l'activité en cours. Sous Windows, la commande `tasklist` offre un affichage similaire.

Si vous souhaitez être plus exhaustif, ajoutez -tout Pour inclure les inactifs, filtrez par statut avec --state= et par type avec --type=serviceDe cette façon, vous pouvez lister, par exemple, toutes les unités de service quelle que soit leur activité.

Pour consulter les éléments installés et leur stratégie de démarrage, la commande `systemctl list-unit-files` affiche les fichiers d'unité et leur état : activé, désactivé, statique ou masqué. L'état « statique » indique les unités sans section, destinées aux dépendances ou à une exécution occasionnelle.

Inspecter les unités, les dépendances et les propriétés

La commande `systemctl cat name.service` affiche le fichier d'unité exact chargé par systemd (y compris les substitutions). C'est idéal pour vérifier quelles directives sont effectivement actives.

Les dépendances sont affichées avec systemctl liste-dépendances. Vous pouvez ajouter --all pour la récursivité, --reverse pour les dépendances inverses, ou --before/--after pour l'ordre relatif entre les unités.

Si vous avez besoin de détails de bas niveau, systemctl afficher vide les propriétés clés au format clave=valorPour quelque chose de spécifique, utilisez -p Propiedad et vous n'obtenez que ce qui vous intéresse (par exemple les conflits ou les relations d'ordre).

Lorsqu'un service ne devrait même pas être démarré, masque-le avec sudo systemctl mask nombre.service (pointe vers /dev/null). Ensuite, il suffit unmask Il le rétablit à son état précédent. Un masque bloque les démarrages manuels et automatiques. Dans les environnements Windows, vous pouvez également restaurer les services endommagés depuis la console Services, par exemple. Restaurer les services supprimés depuis services.msc.

Édition des unités : remplacements et rechargements de démons

Pour personnaliser sans toucher au fichier d'origine, systemctl éditer le nom.service ouvre une substitution dans /etc/systemd/system/nombre.service.d/override.confTout ce que vous y mettez prévaut sans perdre la base du fournisseur.

Si vous souhaitez réécrire l’unité entière, utilisez -complet et enregistrera une copie dans /etc/systemd/system. Lorsque vous supprimez des remplacements ou des unités personnalisées, n'oubliez pas recharger le démon avec sudo systemctl daemon-reload afin qu'il cesse d'y faire référence.

Si vous n’avez plus besoin de vos modifications, vous pouvez supprimer le répertoire .d de la commande de remplacement ou de l'unité complète dans /etc/systemd/system. Après cela, un daemon-reload et le système reviendra aux définitions de base du système.

Cibles et relation avec les niveaux d'exécution

Les cibles représentent des états du système (par exemple, multi-user.target ou graphical.target) et regroupent les unités nécessaires pour atteindre cet état. Elles sont similaires aux anciens niveaux d'exécution, mais plus flexibles et composables.

Interroger la cible par défaut avec systemctl get-default et le changer avec définir par defaut (par exemple, graphical.target pour démarrer dans un environnement graphique). Vous pouvez lister les cibles installées avec list-unit-files --type=target et des actifs avec list-units --type=target.

Si vous devez effectuer un trajet important, isoler Arrête ce qui n'appartient pas à la cible et active ses dépendances. Avant cela, il est judicieux de revoir list-dependencies de la cible afin de ne pas faire tomber accidentellement quelque chose de critique.

De plus, systemctl expose des raccourcis avec des avertissements aux utilisateurs connectés : sauver (mode mono-utilisateur), arrêt, éteindre y rebootSur de nombreuses machines, les commandes traditionnelles telles que reboot sont déjà liés à systemd.

Créez votre propre service (.service) étape par étape

Pour un service sur mesure, créez l'unité en /etc/systemd/système. Par exemple, ttrssupdate.service Il peut contenir une description, des dépendances, l'utilisateur d'exécution et la commande à lancer.

Un exemple typique serait quelque chose comme ceci (adaptez les chemins réels) : avec Description, After, User, ExecStart et WantedBy, vous définissez les éléments essentiels pour que le système multi-utilisateurs démarre.

En ce qui concerne les permis et la propriété, il est important que le fichier appartient à racine et disposez d'autorisations cohérentes. Évitez les autorisations trop permissives ; bien que certains exemples le montrent chmod 777, la pratique recommandée est plus restrictive afin de ne pas ouvrir la porte à des problèmes de sécurité.

Après avoir créé ou modifié l'unité, exécutez sudo systemctl démon-recharger, permet avec enable et commence par start. A partir de là, vous pouvez Arrêtez, recommencer et consulter statuts. Pour déboguer, journalctl -u tu-servicio.service vous montrera le journaux associés.

Équivalents à SysV et autres inits

Si vous venez de SysV, pensez à systemctl démarrer/arrêter/redémarrer/recharger/état comme substituts de service nombre start/stop/.... Pour la partie de départ, activer désactiver remplace chkconfig on/offet liste-fichiers-unités fournit un aperçu de ce qui est activé.

Sur les systèmes plus anciens, vous pouvez rencontrer la commande ` service --status-all` , qui liste les services avec des indicateurs tels que (actif), (inactif) ou (inconnu). Avec Upstart (Ubuntu 14.04, RHEL6), la commande `initctl list` permet d'afficher les états comme `running`, `stopped` ou `waiting`.

Dans les environnements qui utilisent OuvertRC (Gentoo, Alpin), rc-status Affiche les services par niveau d'exécution avec les statuts : démarré, arrêté, en échec ou planté. Vous pouvez même consulter le niveau d'exécution actuel avec rc runlevelPour les tâches avancées de gestion des processus sous Windows, il existe également des outils tiers, par exemple Utilisez Process Hacker pour gérer les priorités.

Diagnostics, journaux et performances de démarrage

Pour vérifier les définitions, systemd-analyze propose des fonctions de contrôle et d'analyse. Vous pouvez obtenir un instantané du processus de démarrage, identifier l'opération la plus longue et générer un graphique SVG.

Commandes courantes : blâme systemd-analyser (fois par service), systemd-analyze chaîne critique (chaîne critique de dépendances) et tracé d'analyse systemd (génère un .svg avec la chronologie de démarrage).

En cas de défaillance d'un service, exécutez `journalctl -u service.name` pour consulter les erreurs et les avertissements. Vous pouvez lister les unités défaillantes et, si l'arrêt ou le redémarrage prend du temps, vérifier si des tâches sont bloquées et les annuler avant de réessayer.

Si vous modifiez ou créez de nouveaux lecteurs, n'oubliez pas d' exécuter la commande systemd-analyze verify pour détecter les erreurs de syntaxe ou les références à des fichiers inexistants avant d'activer et de démarrer le service.

Bonnes pratiques de gestion

Dans les fichiers d'unité, utilisez toujours chemins absolus dans ExecStart/ExecReload et les fichiers de configuration. Ne vous fiez pas aux variables d'environnement telles que $PATH car systemd ne les considérera pas comme le ferait votre shell.

Définir ExecReload si votre service prend en charge la recharge dynamique. Vous pouvez ainsi utiliser systemctl reload à chaud sans redémarrage, ce qui est essentiel pour les serveurs à haute disponibilité.

Configurez RestartSec en complément de vos stratégies de redémarrage pour éviter les boucles de redémarrage intempestives. Un léger délai permet de stabiliser les dépendances et les ressources partagées.

Documenter et surveiller : enregistrer les listes sous systemctl liste-unité-fichiers –type service –all > services.txt, mappe les dépendances avec list-dependencies --reverse et surveille l'état et la consommation. Complétez avec les solutions Prometheus/Grafana ou APM si votre situation l'exige.

Sur les systèmes distants critiques, désactivez le mode d'urgence s'il risque de vous priver d'accès au réseau en cas de mauvaise configuration. Enfin, validez les modifications en environnement de test avant leur mise en production.

Compatibilité, adoption et vision d'entreprise

Bien que systemd soit aujourd'hui prédominant dans la plupart des distributions , il n'est pas universel. Fedora l'a intégré très tôt ; Debian l'utilise depuis la version 8 ; RHEL et CentOS depuis RHEL 7 ; Ubuntu l'a adopté en 15.04 ; Arch et openSUSE l'utilisent depuis des années, entre autres.

Tout n'a pas été que des éloges : sa complexité et son ampleur ont été critiquées , de même que son potentiel à créer une dépendance au sein de l'écosystème et un certain éloignement de la philosophie minimaliste d'Unix . Pour les administrateurs novices, la courbe d'apprentissage peut sembler abrupte.

Parmi les inconvénients pratiques : des problèmes de permissions et de sécurité en cas de configuration incorrecte, des conflits de dépendances possibles, des démarrages plus lents dus à des délais d’attente mal ajustés, ou des dysfonctionnements après les mises à jour si les disques ne sont pas entretenus.

Cela dit, en entreprise, il assure la cohérence, la télémétrie et le contrôle . Sa modularité, sa journalisation intégrée et sa modélisation déclarative des dépendances facilitent le déploiement à grande échelle et réduisent le temps moyen de réparation.

Systemd dans WSL : comment l'activer et ce que cela change

Si vous travaillez sous Windows avec WSL 2, vous pouvez désormais activer systemd pour se rapprocher encore plus d'un Linux bare-metal. Sur Ubuntu actuel installé avec wsl --install Il est déjà fourni par défaut.

Pour les autres distributions sur WSL 2, modifier /etc/wsl.conf et ajoute : dans une ligne et systemd=true dans un autre. Fermer et courir wsl.exe –arrêt en PowerShell pour redémarrer WSL ; à votre retour, vérifiez auprès de systemctl status.

Sur Debian/Ubuntu/Kali, assurez-vous que systemd et systemd-sysv sont installés. Important : en attribuant le PID 1 à systemd, WSL modifie son architecture interne ; cependant, les services ne maintiennent plus l’instance WSL active indéfiniment, comme auparavant.

Pour toute personne développant avec des snaps, des microk8s ou d'autres composants qui s'appuient sur systemd, cette intégration réduit les frictions et rapproche le comportement de ce que vous verrez en production.

Il est important de rappeler que systemd propose également des utilitaires complémentaires comme journalctl pour la journalisation, ou systemd-analyze pour le profilage du démarrage et la vérification des disques. Avec un peu d'organisation et quelques bonnes pratiques, il devient un outil très puissant pour les administrateurs et les ingénieurs DevOps.

Article connexe:

Comment modifier les services dans Windows 11 : contrôle total, sécurité et performances

Isaac

Écrivain passionné par le monde des octets et de la technologie en général. J'aime partager mes connaissances à travers l'écriture, et c'est ce que je vais faire dans ce blog, vous montrer toutes les choses les plus intéressantes sur les gadgets, les logiciels, le matériel, les tendances technologiques et plus encore. Mon objectif est de vous aider à naviguer dans le monde numérique de manière simple et divertissante.