Service Management dans Systemd

Affiche les commandes de base systemctl start et systemctl stop et explique comment les changements 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 conserve le même état.

Si vous arrêtez un service, puis que vous remplacez la cible d'état du système par une cible dans laquelle le service est configuré pour s'exécuter (par exemple, en réinitialisant le système), le service redémarre. De même, le démarrage d'un service ne permet pas au service de démarrer après un redémarrage. Reportez-vous à 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) après les réinitialisations.

Vous pouvez utiliser la commande systemctl pour activer ou désactiver le démarrage d'un service lors de l'initialisation 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 d'état système de niveau le plus bas sur laquelle le service démarre. 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 comme indiqué 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 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 définit la référence de service sur /dev/null. Si vous essayez de démarrer un service qui a été masqué, vous recevrez une erreur comme indiqué dans l'exemple suivant :

sudo systemctl start httpd

Failed to start httpd.service: Unit is masked.

Pour rétablir le lien entre la référence de service et le fichier de configuration de l'unité de service correspondante, 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 la vérification de l'état du service et des groupes de contrôle.

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

systemctl is-active httpd

active

systemctl is-active sshd

inactive

La sous-commande status fournit un récapitulatif détaillé de l'état d'un service, y compris une arborescence qui affiche les tâches du groupe de contrôle (CGroup) implémentées par le service :

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 élément cgroup est un ensemble de processus liés entre eux afin que vous puissiez contrôler leur accès aux ressources système. Dans cet exemple, cgroup pour le service httpd est httpd.service, qui se trouve dans la tranche system.

Les tranches divisent le fichier cgroups d'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 utilisateur, qui s'exécutent dans des groupes cgroups transitoires appelés portées.

Dans cet exemple, les processus de l'utilisateur portant l'ID 1000 sont exécutés dans la portée session-7.scope sous la tranche /user.slice/user-1000.slice.

Vous pouvez utiliser la commande systemctl pour limiter la CPU, les E/S, la mémoire et les autres ressources disponibles pour les processus dans les groupes de services et d'étendue. Reportez-vous à Contrôle de l'accès aux ressources système.

Pour plus d'informations, reportez-vous aux pages de manuel systemctl(1) et systemd-cgls(1). Reportez-vous également à Utilisation de Systemd pour gérer les groupes de contrôle.

Indique comment utiliser systemctl set-property et systemd-run pour affecter des limites de CPU et de mémoire aux services et aux étendues.

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 de CPU. La valeur par défaut étant 1024, une valeur de 512 réduit de moitié l'accès au temps CPU 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 d'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, chargez de nouveau systemd 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 étendues 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 étendue, 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 indiquer 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 dont dispose une étendue aux ressources système de la même manière que pour un service. Cependant, contrairement à un service, vous devez indiquer l'extension .scope, par exemple :

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

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

Explique comment remplacer les fichiers d'unités packagées et créer des fragments de code déposés 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 vers /etc/systemd/system.

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

Les fichiers dans /etc/systemd/system sont prioritaires sur les versions dans /usr/lib/systemd/system. Les fichiers dans /etc/systemd/system ne sont pas écrasés lorsque vous mettez à jour un package 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 des 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-leur une extension de fichier .conf.

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é d'origine.

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.