systemctl envoie des demandes à un gestionnaire systemd. Cette leçon porte sur les unités de services système. Confirmez le nom exact de l'unité, la portée du gestionnaire, les dépendances et l'impact opérationnel avant de changer son état.
Init · Leçon 6
Objectifs de systemd
Découvrez comment examiner, surcharger, valider, démarrer, activer et dépanner les unités de services systemd.
Lire une unité de service
Une unité minimale servant d'exemple peut ressembler à ceci :
[Unit]
Description=Example worker
Wants=network-online.target
After=network-online.target
[Service]
Type=exec
ExecStart=/usr/local/bin/example-worker
Restart=on-failure
[Install]
WantedBy=multi-user.target
[Unit]contient la description et les relations de dépendances.[Service]définit le cycle de vie du processus et le comportement propre au service.[Install]indique aux commandes d'activation les alias ou liens de dépendances à créer ; il ne s'agit pas automatiquement d'une dépendance active à l'exécution.
ExecStart= n'est pas transmis par défaut à un shell. Les pipelines, redirections, variables et guillemets ne se comportent pas comme sur une ligne de commande interactive, sauf si un shell explicite est délibérément appelé.
Quel est le rôle principal des directives [Install] comme WantedBy= ?
Examiner la configuration effective
Répertoriez les unités chargées avec :
$ systemctl list-units --type=service
Répertoriez les fichiers d'unités installés et leur état d'activation avec :
$ systemctl list-unit-files --type=service
Ces vues sont différentes : un fichier d'unité peut être activé mais inactif, actif mais désactivé, statique, généré, transitoire, masqué ou absent de l'une des listes. Examinez le contenu fusionné du fournisseur et des surcharges avec :
$ systemctl cat UNIT.service
$ systemctl show UNIT.service
Qu'affiche list-unit-files que list-units ne présente pas principalement ?
Créer une surcharge locale
Employez une surcharge partielle plutôt que de modifier une unité fournie par un paquet :
$ sudo systemctl edit UNIT.service
Après l'enregistrement, les implémentations actuelles demandent normalement au gestionnaire de se recharger dans le cadre de cette commande. Lorsque des fichiers sont modifiés par une autre méthode, exécutez :
$ sudo systemctl daemon-reload
daemon-reload relit les définitions d'unités et reconstruit les dépendances. Il ne recharge pas la configuration des applications et ne redémarre pas les services actifs. Validez lorsque cela convient la syntaxe et les dépendances avec systemd-analyze verify, puis examinez l'unité fusionnée effective.
Que fait systemctl daemon-reload ?
État d'exécution du service
Après validation de la configuration et préservation de l'accès de récupération :
$ sudo systemctl start peanut.service
$ sudo systemctl stop peanut.service
$ sudo systemctl restart peanut.service
$ sudo systemctl reload peanut.service
reload ne réussit que si l'unité définit ou prend en charge une action de rechargement. restart interrompt le processus et peut ne pas rétablir le service. Pour l'accès distant, le réseau, le stockage ou l'authentification, conservez une console distincte et vérifiez la configuration avant d'agir.
Contrôlez l'état et les journaux avec :
$ systemctl status peanut.service
$ systemctl is-active peanut.service
$ journalctl -u peanut.service -b
« Active » décrit l'état du gestionnaire, mais ne prouve pas que chaque point d'accès applicatif est sain.
Quelle commande démarre peanut.service maintenant sans modifier à elle seule son activation future ?
Activation, désactivation et masquage
Gérez les futurs liens de dépendances avec :
$ sudo systemctl enable peanut.service
$ sudo systemctl disable peanut.service
Enable ne démarre pas l'unité sans --now. Disable n'arrête pas une unité active sans --now. Une unité statique peut ne pas posséder de métadonnées d'installation et être tout de même activée comme dépendance d'une autre unité.
Le masquage lie l'unité à /dev/null et bloque son activation ordinaire, y compris par dépendance, jusqu'à ce qu'elle soit démasquée. Il est plus fort que la désactivation et peut casser les dépendants ; examinez les dépendances inverses avant de l'employer.
Que devient un service déjà actif après systemctl disable UNIT sans --now ?
Vérifier le résultat du service
Après un changement, vérifiez l'état du processus, les journaux récents, les points d'écoute, les unités dépendantes, la santé de l'application et le comportement après un redémarrage contrôlé si l'activation au démarrage a changé. Employez systemctl is-failed, systemctl list-dependencies et les contrôles natifs de l'application selon les besoins.
Leçon terminée
Vous avez terminé Objectifs de systemd
Vous savez maintenant gérer un service systemd sans confondre configuration, exécution et activation.
Lire
[Unit],[Service]et[Install]selon leurs rôles distincts.Comparer l'état des unités chargées à celui des fichiers d'unités installés.
Employer des surcharges partielles et recharger le gestionnaire après des modifications externes.
Démarrer, arrêter, recharger ou redémarrer seulement après examen de l'impact.
Considérer enable, disable et mask comme des contrôles de persistance distincts.
Conservez votre progression
Créez un compte gratuit pour enregistrer cette leçon et continuer sur n'importe quel appareil.
Créer un compte gratuit