Gestion des services sur RHEL 7 avec systemd

Samuel Chevalley
20 septembre 2016

Depuis RHEL 7, la gestion des services est différente de RHEL 6, 5 …

Comparaison de l’utilisation des services avec « systemctl »

service systemctl Description
service name start systemctl start name Démarrer un service
service name stop systemctl stop name Stoper un service
service name restart systemctl restart name Redémarrer un sevrice
service name condrestart systemctl try-restart name Redémarrer un service que si il est déjà lancé
service name reload systemctl reload name Recharger la configuration
service name status systemctl status name

systemctl is-active name

Checker si le service est lancé
service –status-all systemctl list-units –type service –all Afficher le statut du service

Comparaison de l’utilisation de chkconfig avec « systemctl »

chkconfig systemctl Description
chkconfig name on systemctl enable name Activer un service
chkconfig name off systemctl disable name Désactiver un service
chkconfig –list name systemctl status name

systemctl is-enabled name

Checker si un service est activé
chkconfig –list systemctl list-unit-files –type service Lister tous les services et voir si ils sont activé

 

Créer son service

Systemd defini differents types de services :

– Un service de type simple (type par défaut) lance un processus principal. Dans le cas où ce processus offre une fonctionnalité à d’autre processus sur le système, ses canaux de communication doivent être installés avant que le processus principal soit démarré. Ce qui est rendu possible par l’activation des sockets, et autres canaux de communication. Ainsi, systemd peut traiter les autres unités sans se préoccuper de la fin du lancement d’une unité de type « simple ».

– Un service de type forking, lance un processus père qui créera un processus fils dans le cadre de son démarrage. Le processus parent est prévu pour s’arrêter une fois le démarrage complet et que tous les canaux de communication sont mis en place. Le processus fils continue à fonctionner en tant que le processus principal du service. systemd poursuit le traitement des autres unités une fois que le processus père se termine. Ce type de service correspond aux services UNIX traditionnels.

– Un service de type oneshot est similaire à un service de type simple. Cependant, systemd attend que le processus se termine avant de continuer ses traitements. Ce type de service est typiquement utilisé comme équivalent aux commandes lancées au démarrage via les scripts d’init system V. Cela permet à systemd de remplacer ce mécanisme. De ce fait, avec systemd des nouveaux services apparaissent, alors qu’ils auraient été simplement des scripts d’init avec SysVinit.

– Un service de type dbus est similaire à un service de type simple. Cependant, le processus du service doit obtenir un nom via D-Bus. systemd pourra alors traiter les autres unités.

– Un service de type notify est similaire à un service de type simple. Cependant, c’est le processus du service qui avertira systemd (via la fonction sd_notfy(3)) qu’il peut traiter les autres unités.

 

Exemple

Créer le fichier /etc/systemd/system/serviceTest.service et indiquer :

[Unit]
Description=Mon service de test
After=network.target
[Service]
Type=simple
ExecStart=/usr/bin/test-daemon
[Install]
WantedBy=multi-user.target

 

La section [Unit] contient de l’information générique sur le service (« After » permet de spécifier au service de démarrer ici après que le réseau soit up).
La section [Service] concerne l’information sur le service en lui-même (« ExecStart » permet de spécifier le chemin du service à lancer).
La section [Install] s’occupe des circonstances et des déclencheurs dans le cadre desquels le service devrait être démarré (« WantedBy » permet de spécifier dans quel Target doit être actif le service. Ici, en spécifiant « multi-user.target », le service est actif dans les Runlevels 2, 3, 4 et 5).

 

Pour toutes les options, voir : https://www.freedesktop.org/software/systemd/man/systemd.service.html