Gestion des services sur RHEL 7 avec systemd
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