Centreon vous déconnecte au bout de quelques minutes ou d’une poignée d’heures d’inactivité ? Ce tutoriel montre, pas à pas, comment porter la durée des sessions à plusieurs heures ou plusieurs jours — sous Debian comme sous RHEL/Rocky/AlmaLinux. Le point important : il faut agir sur deux couches, et la seconde recèle un piège qui fait échouer la plupart des réglages.
Deux sessions, pas une
Quand Centreon vous déconnecte, la durée réellement appliquée est celle du maillon le plus court parmi :
- Le timeout applicatif Centreon — le paramètre
session_expire, réglable dans l’interface. Par défaut 120 minutes (2 heures). - La session PHP — Centreon est servi par php-fpm ; si PHP purge le fichier de session avant, vous êtes déconnecté, quelle que soit la valeur côté Centreon. C’est ici que se cache le piège.
- Un éventuel proxy d’authentification (SSO/reverse proxy devant Centreon) — il a lui aussi sa propre durée de session à aligner.
Régler l’un sans l’autre ne sert à rien : il faut que les deux (voire trois) couches dépassent la durée voulue.
Rappel d’unités : minutes ou secondes ?
Piège classique : les deux couches n’utilisent pas la même unité. Centreon (session_expire) se règle en minutes, tandis que PHP (gc_maxlifetime, cookie_lifetime) se règle en secondes. Une même durée s’écrit donc de deux façons différentes :
| Durée | Centreon — minutes | PHP — secondes |
|---|---|---|
| 2 heures | 120 |
7200 |
| 1 jour | 1440 |
86400 |
| 7 jours | 10080 |
604800 |
| 30 jours | 43200 |
2592000 |
Le calcul pour les valeurs « 30 jours » utilisées plus bas : côté PHP, 30 × 24 × 3600 = 2 592 000 secondes ; côté Centreon, 30 × 24 × 60 = 43 200 minutes.
Étape 1 — Le timeout applicatif Centreon
Dans l’interface : Administration → Paramètres → Centreon UI, champ « Durée d’expiration de session » (session_expire), exprimé en minutes. Exemples : 10080 pour 7 jours, 43200 pour 30 jours.
En ligne de commande, la valeur est stockée dans la table options :
-- 30 jours = 43200 minutes
UPDATE options SET `value` = '43200' WHERE `key` = 'session_expire';Attention : ce réglage seul ne suffit pas. Si la couche PHP purge la session à 24 minutes, vous serez déconnecté à 24 minutes malgré ce paramètre. Passons donc au vrai nerf de la guerre.
Étape 2 (Debian) — La session PHP
Sous Debian, la garbage collection probabiliste de PHP est désactivée (session.gc_probability = 0). Le ménage est confié à un script système, /usr/lib/php/sessionclean, déclenché toutes les 30 minutes par un timer systemd. Et c’est là que ça se corse.
1. Poser les réglages dans un module dédié
On crée un fichier propre (adaptez 8.2 à votre version PHP). Ici, 30 jours :
cat > /etc/php/8.2/mods-available/centreon-session.ini <<'EOF'
; Session Centreon longue — durée serveur et cookie (en secondes)
session.gc_maxlifetime = 2592000 ; 30 jours (30 x 24 x 3600)
session.cookie_lifetime = 2592000 ; 30 jours
EOF2. Activer le module sur TOUTES les SAPI (l’étape qu’on oublie)
Centreon tourne sous php-fpm, mais le nettoyeur, lui, regarde toutes les SAPI (fpm, cli et apache2). Il faut donc activer le réglage partout :
phpenmod -v 8.2 centreon-session
# Vérifier les liens : les trois SAPI doivent apparaître
ls -l /etc/php/8.2/*/conf.d/*centreon-session*Si une SAPI manque — souvent apache2, qui reste au défaut de 24 minutes — créez le lien à la main :
ln -sf /etc/php/8.2/mods-available/centreon-session.ini \
/etc/php/8.2/apache2/conf.d/50-centreon-session.ini3. Vérifier la valeur effective, SAPI par SAPI
Ne vous fiez pas au php.ini : mesurez ce que verra réellement sessionclean. Les trois lignes doivent afficher la même durée longue :
for sapi in apache2 fpm cli; do
eff=$(PHP_INI_SCAN_DIR=/etc/php/8.2/$sapi/conf.d/ \
php8.2 -c /etc/php/8.2/$sapi/php.ini \
-r 'echo ini_get("session.gc_maxlifetime")," / ",session_save_path();')
echo "$sapi : $eff"
doneapache2 : 2592000 / /var/lib/php/sessions
fpm : 2592000 / /var/lib/php/sessions
cli : 2592000 / /var/lib/php/sessionsSi une SAPI affiche encore 1440 (24 minutes) sur ce même dossier, c’est elle qui purgera tout à 24 minutes — même si les autres sont à 30 jours.
4. Redémarrer php-fpm
systemctl restart php8.2-fpmLa purge serveur est corrigée dès le prochain passage du timer (aucun redémarrage requis pour cet aspect), mais le redémarrage est nécessaire pour que le nouveau cookie_lifetime s’applique aux nouveaux cookies.
Le piège qui fait tout échouer
Le timer exécute /usr/lib/php/sessionclean, qui itère sur toutes les SAPI. Pour chacune, il calcule la durée effective et son save_path, puis lance indépendamment :
find "$save_path" -depth -mindepth 1 -name 'sess_*' -type f -cmin "+$duree_minutes" -deleteOr apache2, fpm et cli partagent le même /var/lib/php/sessions. Si une seule est restée à 24 min (typiquement apache2, car libapache2-mod-php est souvent installé en dépendance), cette entrée efface tout le dossier commun toutes les 30 minutes — y compris les sessions Centreon servies par php-fpm. C’est pourquoi régler « seulement fpm » ne marche jamais. À noter aussi : un php_value[session.gc_maxlifetime] mis dans le pool FPM de Centreon n’a aucun effet ici, car sessionclean lit le php.ini + conf.d de la SAPI, pas le pool.
Retour d’expérience. Ce plancher de 24 minutes est latent et masqué tant qu’on est actif : chaque clic rafraîchit l’horodatage du fichier de session, qui ne vieillit donc jamais assez pour être purgé. Sur une instance Centreon réelle, la session semblait durer 2 heures — en fait le simple
session_expirepar défaut (120 min) — parce que l’admin ne restait jamais inactif 24 min. Le jour où l’on a voulu passer à 7 jours en laissant l’onglet inactif, le vrai plancher de 24 min est apparu… et le réglage 7 jours, posé uniquement surfpmetcli, ne l’a pas corrigé : la SAPIapache2continuait de purger le dossier partagé. La leçon : régler toutes les SAPI, et tester en inactivité, pas en cliquant.
Étape 2 (RHEL / Rocky / AlmaLinux) — La session PHP
La famille RHEL ne suit pas la même logique : pas de sessionclean ni de timer. Le nettoyage est assuré par la garbage collection probabiliste native de PHP (gc_probability = 1, gc_divisor = 1000 par défaut), exécutée pendant les requêtes. C’est le php-fpm de Centreon lui-même qui purge, avec sa valeur — donc pas de piège multi-SAPI par timer.
1. Poser les réglages
Globalement dans /etc/php.d/zz-centreon-session.ini (valeurs en secondes) :
session.gc_maxlifetime = 2592000 ; 30 jours
session.cookie_lifetime = 2592000 ; 30 jours…ou ciblé dans le pool /etc/php-fpm.d/centreon.conf :
php_value[session.gc_maxlifetime] = 2592000 ; 30 jours
php_value[session.cookie_lifetime] = 25920002. Redémarrer (obligatoire ici)
systemctl restart php-fpmVérifiez au passage les permissions de /var/lib/php/session : si php-fpm ne peut pas y supprimer les fichiers, la GC échoue silencieusement. Et si httpd/mod_php coexiste avec php-fpm sur le même save_path, le même piège de dossier partagé peut réapparaître.
Vérifier que ça marche
- Test réel : connectez-vous à Centreon, laissez l’onglet inactif plus longtemps que l’ancien plancher (30-40 min), puis rechargez une page. Vous devez rester connecté.
- Âge des sessions : après plus de 24 min d’inactivité, les fichiers doivent toujours être là :
ls -l /var/lib/php/sessions/. - Debian : forcez le nettoyeur et vérifiez qu’il ne supprime rien :
systemctl start phpsessionclean.service.
Debian vs RHEL — récapitulatif
| Debian | RHEL / Rocky / Alma | |
|---|---|---|
| GC probabiliste PHP | Désactivée (gc_probability = 0) |
Active (1/1000) |
| Qui purge | Script sessionclean + timer (30 min) |
Le processus php-fpm lui-même |
| Où régler | mods-available activé sur toutes les SAPI |
/etc/php.d/ ou php_value[] du pool |
| Piège principal | Purge par SAPI sur un save_path partagé |
Coexistence mod_php + php-fpm sur le même save_path |
| Restart php-fpm | Non pour la purge ; oui pour le cookie | Oui |
Bonnes pratiques
- Régler les deux couches :
session_expirecôté Centreon et la session PHP côté serveur. - Mesurer la valeur effective par SAPI — jamais se fier au seul
php.ini. - Toutes les SAPI partageant un
save_pathsont gouvernées par la durée la plus courte. - Aligner
gc_maxlifetimeetcookie_lifetimesur la même valeur. - Tester en inactivité, pas en cliquant — sinon le plancher réel reste masqué.
- Si Centreon est derrière un SSO/reverse proxy, aligner aussi la durée de session de ce dernier.
Une fois le bon réflexe acquis — régler les deux couches et vérifier l’effectif sur toutes les SAPI — porter une session Centreon à 30 jours tient en quelques lignes. Le plus dur, c’est de savoir où regarder.
