Service Management dans Systemd

La figure présente les commandes de base systemctl start et systemctl stop et explique comment les modifications d'état persistent.

Pour démarrer un service, utilisez la commande systemctl start :

sudo systemctl start sshd

Pour arrêter un service, utilisez la commande systemctl stop :

sudo systemctl stop sshd

La modification de l'état d'un service ne dure que lorsque le système reste dans le même état.

Si vous arrêtez un service, puis que vous remplacez la cible de l'état système par une cible dans laquelle le service est configuré pour s'exécuter (par exemple, en redémarrant le système), le service redémarre. De même, le démarrage d'un service ne permet pas au service de commencer à suivre un redémarrage. Voir Activation et désactivation des services.

Explique comment activer, désactiver, masquer et démasquer les services afin qu'ils démarrent (ou restent arrêtés) lors des redémarrages.

Vous pouvez utiliser la commande systemctl pour activer ou désactiver un service à partir du démarrage du système, par exemple :

sudo systemctl enable httpd

Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.

La commande enable active un service en créant un lien symbolique pour la cible système-état de niveau le plus bas à laquelle le service commence. Dans l'exemple précédent, la commande crée le lien symbolique httpd.service pour la cible multi-user.

La désactivation d'un service supprime le lien symbolique :

sudo systemctl disable httpd

Removed /etc/systemd/system/multi-user.target.wants/httpd.service.

Pour vérifier si un service est activé, utilisez la sous-commande is-enabled (Activé), comme illustré dans les exemples suivants :

systemctl is-enabled httpd

disabled

systemctl is-enabled sshd

enabled

Après l'exécution de la commande systemctl disable, le service peut toujours être démarré ou arrêté par des comptes d'utilisateur, des scripts et d'autres processus.

Toutefois, si vous devez vous assurer que le service ne peut pas être démarré par inadvertance, par exemple par un service en conflit, utilisez la commande systemctl mask comme suit :

sudo systemctl mask httpd

Created symlink from '/etc/systemd/system/multi-user.target.wants/httpd.service' to '/dev/null'

La commande mask règle la référence du service à /dev/null. Si vous essayez de démarrer un service qui a été masqué, vous recevrez une erreur, comme illustré dans l'exemple suivant :

sudo systemctl start httpd

Failed to start httpd.service: Unit is masked.

Pour lier de nouveau la référence de service au fichier de configuration d'unité de service correspondant, utilisez la commande systemctl unmask :

sudo systemctl unmask httpd

Pour plus d'informations, consultez la page de manuel systemctl(1).

Détails des commandes systemctl is-active et status pour vérifier l'état du service et les groupes de contrôle.

Pour vérifier si un service est en cours d'exécution, utilisez la sous-commande is-active. La sortie serait active ou inactive, comme illustré dans les exemples suivants :

systemctl is-active httpd

active

systemctl is-active sshd

inactive

La sous-commande de statut fournit un sommaire détaillé du statut d'un service, y compris une arborescence qui affiche les tâches dans le groupe de contrôle (CGroup) que le service met en oeuvre :

systemctl status httpd

httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since ...
     Docs: man:httpd.service(8)
 Main PID: 11832 (httpd)
   Status: "Started, listening on: port 80"
    Tasks: 213 (limit: 26213)
   Memory: 32.5M
   CGroup: /system.slice/httpd.service
           ├─11832 /usr/sbin/httpd -DFOREGROUND
           ├─11833 /usr/sbin/httpd -DFOREGROUND
           ├─11834 /usr/sbin/httpd -DFOREGROUND
           ├─11835 /usr/sbin/httpd -DFOREGROUND
           └─11836 /usr/sbin/httpd -DFOREGROUND

Jul 17 00:14:32 Unknown systemd[1]: Starting The Apache HTTP Server...
Jul 17 00:14:32 Unknown httpd[11832]: Server configured, listening on: port 80
Jul 17 00:14:32 Unknown systemd[1]: Started The Apache HTTP Server.

Un cgroup est un ensemble de processus liés entre eux afin que vous puissiez contrôler leur accès aux ressources système. Dans l'exemple, cgroup pour le service httpd est httpd.service, qui se trouve dans la tranche system.

Les tranches divisent le cgroups sur un système en différentes catégories. Pour afficher la tranche et la hiérarchie cgroup, utilisez la commande systemd-cgls :

systemd-cgls

Control group /:
-.slice
├─user.slice
│ └─user-1000.slice
│   ├─user@1000.service
│   │ └─init.scope
│   │   ├─6488 /usr/lib/systemd/systemd --user
│   │   └─6492 (sd-pam)
│   └─session-7.scope
│     ├─6484 sshd: root [priv]
│     ├─6498 sshd: root@pts/0
│     ├─6499 -bash
│     ├─6524 sudo systemd-cgls
│     ├─6526 systemd-cgls
│     └─6527 less
├─init.scope
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 16
└─system.slice
  ├─rngd.service
  │ └─1266 /sbin/rngd -f --fill-watermark=0
  ├─irqbalance.service
  │ └─1247 /usr/sbin/irqbalance --foreground
  ├─libstoragemgmt.service
  │ └─1201 /usr/bin/lsmd -d
  ├─systemd-udevd.service
  │ └─1060 /usr/lib/systemd/systemd-udevd
  ├─polkit.service
  │ └─1241 /usr/lib/polkit-1/polkitd --no-debug
  ├─chronyd.service
  │ └─1249 /usr/sbin/chronyd
  ├─auditd.service
  │ ├─1152 /sbin/auditd
  │ └─1154 /usr/sbin/sedispatch
  ├─tuned.service
  │ └─1382 /usr/libexec/platform-python -Es /usr/sbin/tuned -l -P
  ├─systemd-journald.service
  │ └─1027 /usr/lib/systemd/systemd-journald
  ├─atd.service
  │ └─1812 /usr/sbin/atd -f
  ├─sshd.service
  │ └─1781 /usr/sbin/sshd

system.slice contient des services et d'autres processus système. user.slice contient des processus d'utilisateur, qui s'exécutent dans des cgroups transitoires appelés portées.

Dans l'exemple, les processus pour l'utilisateur portant l'ID 1000 s'exécutent dans l'étendue session-7.scope sous la tranche /user.slice/user-1000.slice.

Vous pouvez utiliser la commande systemctl pour limiter les ressources d'UC, d'E/S, de mémoire et autres disponibles pour les processus dans les cgroups de service et de portée. Voir Contrôle de l'accès aux ressources du système.

Pour plus d'informations, consultez les pages de manuel systemctl(1) et systemd-cgls(1). Voir aussi Utilisation de Systemd pour gérer les groupes de contrôle.

Décrit comment utiliser systemctl set-property et systemd-run pour affecter des limites d'UC et de mémoire aux services et aux portées.

Utilisez la commande systemctl pour contrôler l'accès d'un cgroup aux ressources système, par exemple :

sudo systemctl [--runtime] set-property httpd CPUShares=512 MemoryLimit=1G

CPUShare contrôle l'accès aux ressources d'UC. Comme la valeur par défaut est 1024, une valeur de 512 réduit de moitié le temps d'accès à l'UC dont disposent les processus dans cgroup. De même, MemoryLimit contrôle la quantité maximale de mémoire que cgroup peut utiliser.

Vous pouvez également modifier les paramètres de ressource pour un service sous l'en-tête [Service] dans le fichier de configuration du service dans /usr/lib/systemd/system. Après avoir modifié le fichier, faites en sorte que systemd recharge ses fichiers de configuration, puis redémarrez le service :

sudo systemctl daemon-reload
sudo systemctl restart service

Vous pouvez exécuter des commandes générales dans les portées et utiliser systemctl pour contrôler l'accès que ces cgroups transitoires ont aux ressources système. Pour exécuter une commande dans une portée, utilisez la commande systemd-run :

sudo systemd-run --scope --unit=group_name.scope [--slice=slice_name]

Si vous ne voulez pas créer le groupe sous la tranche system par défaut, vous pouvez spécifier une autre tranche ou le nom d'une nouvelle tranche. L'exemple suivant exécute une commande nommée mymonitor dans mymon.scope sous myslice.slice :

sudo systemd-run --scope --unit=mymon.scope --slice=myslice mymonitor

Running as unit mymon.scope.

Vous pouvez ensuite utiliser systemctl pour contrôler l'accès d'une portée aux ressources système de la même manière que pour un service. Toutefois, contrairement à un service, vous devez spécifier l'extension .scope, par exemple :

sudo systemctl --runtime set-property mymon.scope CPUShares=256

Pour plus d'informations, voir Utilisation de Systemd pour gérer les groupes de contrôle et les pages de manuel systemctl(1), systemd-cgls(1) et systemd.resource-control(5).

Décrit comment remplacer les fichiers d'unité emballés et créer des extraits de code de dépôt sous /etc/systemd/system.

Pour modifier la configuration des services systemd, copiez les fichiers avec les extensions .service, .target, .mount et .socket de /usr/lib/systemd/system à /etc/systemd/system.

Après avoir copié les fichiers, vous pouvez modifier les versions dans /etc/systemd/system.

Les fichiers dans /etc/systemd/system ont préséance sur les versions dans /usr/lib/systemd/system. Les fichiers dans /etc/systemd/system ne sont pas remplacés lorsque vous mettez à jour un ensemble qui touche des fichiers dans /usr/lib/systemd/system.

Pour rétablir la configuration systemd par défaut pour un service particulier, vous pouvez renommer ou supprimer les copies dans /etc/systemd/system.

Une autre approche pour modifier la configuration d'un service consiste à créer un fichier de dépôt. Avec cette approche, vous pouvez conserver l'unité d'origine tout en modifiant les paramètres spécifiques de l'unité.

Créez des fichiers de dépôt dans /etc/systemd/system/unit_name.d/, où le répertoire unit_name.d est une unité existante, puis donnez une extension de fichier .conf aux fichiers de dépôt.

Par exemple : /etc/systemd/system/unit_name.d/name_of_drop-in.conf. systemd lit le fichier .conf et applique les paramètres à l'unité initiale.

Les sections suivantes décrivent les différentes parties d'un fichier d'unité de service que vous pouvez modifier et personnaliser pour un système.