Tâche #36244
Scénario #36045: EOLE 2.10 : service eole-sso en failed après reconfigure
Étude
100%
Historique
#1 Mis à jour par Benjamin Bohard il y a plus d'un an
- Statut changé de Nouveau à En cours
#2 Mis à jour par Benjamin Bohard il y a plus d'un an
L’ajout de l’option --replace dans la commande ExecStart ne semble pas impacter négativement le redémarrage du service (au moins lorsqu’on ne tombe pas dans le timeout).
#3 Mis à jour par Benjamin Bohard il y a plus d'un an
Il est possible que l’option --replace ne suffise pas à résoudre le problème de démarrage : est-ce qu’un conteneur en phase d’arrêt peut être remplacé ?.
Dans le log fourni, on voit que la commande podman stop n’obtient pas le résultat attendu en envoyant le signal SIGTERM. Après le timeout par défaut de 10 secondes, le signal SIGKILL est finalement envoyé mais systemd n’obtient pas davantage la confirmation de l’arrêt du service.
A priori, il ne suffira pas de modifier le timeout pour résoudre le problème courant (dont les conditions de reproduction sont encore mal définies).
#4 Mis à jour par Benjamin Bohard il y a plus d'un an
Le signal TERM n’est pas pris en compte par le conteneur eole-sso (l’arrêt n’est pas déclenché lorsque on lance la commande podman kill --signal TERM eolesso).
Le signal KILL arrête bien le conteneur mais celui-ci est redémarré (option Restart=always dans la configuration du service).
À la différence de ce qui est rapporté, la séquence suivante est observée lors du reconfigure :
nov. 04 10:50:40 scribe systemd[1]: Stopping eole-sso.service - Eole Single Sign On server... nov. 04 10:50:50 scribe eolesso[483372]: time="2024-11-04T10:50:50+01:00" level=warning msg="StopSignal SIGTERM failed to stop container eolesso in 10 seconds, resorting to SIGKILL" nov. 04 10:50:50 scribe podman[478049]: 2024-11-04 10:50:50.397670375 +0100 CET m=+301.288084578 container died fa32ebe598cf1612765a865391a5f9878a76c16082206e2e9043e93b50e46f23 (image=hub.eole.education/eole/eole-sso-server:dev, name=eolesso, org.opencontainers.image.version=20.04, org.opencontainers.image.ref.name=ubuntu)
Le premier signal (TERM) est sans effet, comme rapporté mais le second signal (KILL) a un effet immédiat (et sans redémarrage quand il est déclenché dans ce contexte).
#5 Mis à jour par Benjamin Bohard il y a plus d'un an
- Statut changé de En cours à À valider
#6 Mis à jour par Laurent Gourvenec il y a plus d'un an
- Statut changé de À valider à Résolu
- % réalisé changé de 0 à 100
#7 Mis à jour par Joël Cuissinat il y a plus d'un an
- Statut changé de Résolu à Fermé
- Restant à faire (heures) mis à 0.0