Module Apache mod_systemd

Langues Disponibles: en | fr

Description:	Fournit un support amélioré pour l'intégration de systemd
Statut:	Extension
Identificateur de Module:	systemd_module
Fichier Source:	mod_systemd.c
Compatibilité:	Disponible à partir de la version 2.4.42 du serveur HTTP Apache

Sommaire

Ce module implémente le support de l'intégration de systemd. Il permet d'utiliser httpd en temps que service avec le paramètre de systemd Type=notify ou Type=notify-reload (voir la page de manuel systemd.service(5) pour plus de détails). Le module est activé s'il est chargé.

Exemple basique d'unité de service systemd (à étoffer pour un système en production)

[Unit]
Description=The Apache HTTP Server
After=network.target

[Service]
Type=notify
ExecStart=/usr/local/apache2/bin/httpd -D FOREGROUND -k start
ExecReload=/usr/local/apache2/bin/httpd -k graceful
KillMode=mixed

[Install]
WantedBy=multi-user.target

Si vous utilisez ExecStop et/ou KillMode, vous devez prêter une attention particulière à leur configuration pour ce service. Si elle est présente, une commande ExecStop doit être une operation synchrone qui se termine elle-même en même temps que le démon. Cette condition n'est pas satisfaite si vous exécutez la commande httpd -k stop de manière asynchrone, car elle initie l'arrêt du démon. L'exemple ci-dessus utilise KillMode=mixed afin que systemd envoie SIGTERM au processus parent (et seulement à ce dernier) pour lui indiquer qu'il doit s'arrêter. Les processus encore en cours d'exécution après un temps égal à TimeoutStopSec recevront alors le signal SIGKILL. Voir systemd.kill(5) pour plus d'informations.

À partir de la version 253 de systemd, un gestionnaire de service fournit Type=notify-reload qu’il est préférable d’utiliser. Avec Type=notify, systemctl reload quitte dès que la commande ExecReload a envoyé son signal, ce qui se produit avant que la nouvelle configuration n’ait été lue, et elle indique une exécution réussie quoi qu’il se passe au cours du redémarrage suivant. Type=notify-reload, quant à lui, maintien le rechargement ouvert jusqu’à ce que le serveur indique qu’il a terminé, de sorte que la commande attende que la nouvelle configuration soit prise en compte, et échoue si ce n’est pas le cas. mod_systemd envoie la notification RELOADING=1 que le protocole attend pendant la lecture de la configuration, estampillée de l’étiquette MONOTONIC_USEC requise par le gestionnaire de services, et READY=1 quand elle a été chargée.

Un exemple d’unité de service qui recharge de manière synchrone

[Service]
Type=notify-reload
ReloadSignal=SIGCONT
ExecStart=/usr/local/apache2/bin/httpd -D FOREGROUND -k start
ExecReload=/usr/local/apache2/bin/httpd -k graceful
KillMode=mixed

Le gestionnaire de service exécute tout d’abord ExecReload, puis n’envoie le signal spécifié par ReloadSignal que lorsque la commande a quitté avec succès. Conserver ExecReload rend le rechargement de la configuration sûr : httpd -k graceful analyse la nouvelle configuration dans un processus qui lui est propre et quitte sans rien signaler si l’analyse échoue ; dans ce cas, le rechargement de la configuration échoue et le serveur en cours d’exécution continue avec la configuration qu’il utilise déjà. Omettre ExecReload et laisser le gestionnaire de service informer le serveur directement empêche cette vérification : le processus parent en cours d’exécution lit la nouvelle configuration lui-même, et une configuration dont l’analyse échoue le fait quitter, ce qui arrête le serveur.

Le signal envoyé une fois ExecReload exécutée est alors redondant ; ReloadSignal devrait donc en spécifier un dont httpd ne tient pas compte, tel que SIGCONT. Il est important qu’il soit défini : le signal par défaut est SIGHUP que httpd interprète comme un redémarrage forcé en fermant les connexions qu’un redémarrage est censé préserver. Une unité qui utilise ExecReload doit définir ReloadSignal=SIGUSR1, le signal avec lequel httpd redémarre en douceur.

L’activation du socket de systemd est prise en charge si httpd a été construit en ce sens. Chaque port spécifié par la directive Listen doit alors avoir été indiqué par systemd ; tout port qui ne l’a pas été générera une erreur de configuration fatale et httpd ne l’ouvrira pas pour lui-même. L’activation du socket n’est utilisée que si ce module est chargé ; il peut donc être construit et gardé inutilisé.

ExtendedStatus est activé par défaut si le module est chargé. Si ExtendedStatus n'est pas explicitement désactivé dans le fichier de configuration, les statistiques à propos de la charge et des requêtes pendant l'exécution apparaîtront dans la sortie de la commande systemctl status.

systemd watchdog est pris en charge. Si l’unité de service définit WatchdogSec=, le processus parent envoie la notification de persistance qui informe systemd que le serveur est encore en vie ; un serveur qui cesse de l’envoyer est arrêté et redémarré avec une définition de Restart= appropriée. La notification est envoyée pendant la lecture de la configuration et à nouveau une fois qu’elle a été chargée, de sorte qu’un rechargement soit pris en compte périodiquement par le processus parent pendant l’exécution du serveur.

Cette notification périodique est envoyée environ toutes les dix secondes, ce qui correspond à la périodicité avec laquelle le processus parent exécute le programme d’accroche à partir duquel elle est envoyée. Une valeur de WatchdogSec= inférieure à deux fois cette période ne conviendrait pas, car systemd arrêterait un serveur qui fonctionne normalement ; un tel réglage est signalé sous forme d’avertissement au démarrage. Utilisez une valeur d’au moins 20 secondes pour WatchdogSec=.

Ajouter une supervision watchdog à une des unités ci-avant

[Service]
WatchdogSec=30
Restart=on-failure

Directives

Ce module ne fournit aucune directive.