Bonjour,
 
Pour les besoins spécifiques d'une appli web (un intranet), dans mon script de configuration, je fais ça :

ini_set('session.cookie_lifetime', '36000');
ini_set("session.gc_maxlifetime", '36000');
ini_set('session.cache_expire', '600');

C'est pour allonger la durée de la session (au lieu des 20 mins par défaut dans le php.ini)
 
Bizarrement, depuis quelques jours, cela n'a plus d'effet. C'est la valeur par défaut du php.ini qui a l'air d'être prise en compte. Pourtant, un ini_get() des ces variables de session me renvoie bien les nouvelles valeurs et ini_get_all() aussi.
 
Est-ce que ça dit qq chose à qq'un ce genre de pb?
 
Je précise que c'est sous Linux, en php 5.
Merci par avance de votre aide

ini_set('session.cookie_lifetime', '36000');
ini_set("session.gc_maxlifetime", '36000');
ini_set('session.cache_expire', '600');

 
Y'a pas mal de possibilités...
 
Est-ce que tu configures bien ces valeurs avant de lancer la session?
 
Est-ce que tu configures bien ces valeurs partout où tu lances une session? (y compris sur d'autres sites qui utiliseraient le même chemin, pour enregistrer les fichiers de session).
 
Il peut aussi y avoir des problèmes si on désactive la gestion du atime (access time, souvent désactivé, pour améliorer les performances sur les systèmes de fichier avec beaucoup d'accès), sur le système de fichier qui contient les fichiers de session (le garbage collector ne prend alors plus en compte que la dernier modification de la session, plutôt que le dernier accès à la session).
 
Sinon, tu peux essayer de tester si ça fait pareil en réglant ces valeurs dans un .htaccess, ou dans la configuration du vhost, voir de tout Apache (avec "php_value session.gc_maxlifetime 36000" ). Et tu peux pas modifier directement le php.ini, si tu contrôles le serveur? (au moins pour tester si le problème vient pas d'ailleurs).
 
Et t'es sûr que le problème vient pas de vos navigateurs?

 
Le atime désactivé, j'en ai entendu parlé effectivement. Comment je peux voir que c'est désactivé? J'ai la chance d'avoir accès à mon ancien serveur sur lequel ça marchait très bien. Si tu m'indiques comment on peut voir ça, je pourrais comparer.
Pour info, j'ai fait un script qui analyse les fichiers sessions et m'indique la date dernière accès à la session. je récupère cette info via filemtime() (et non fileatime()).
 
Je précise que je n'ai pas accès à la conf d'apache ou php.ini. Cela dit, je peux la faire modifier. Bien sûr que la solution simple, ça serait de figer ces paramètres dans php.ini, mais ça impacterait toutes les autres applis qui tournent sur le serveur : or, cette extension de durée de session n'a de sens que pour l'appli intranet.

 
Exécute `mount`, sans argument, sur le système qui héberge le serveur, et regarde les options listées pour le système de fichier qui héberge le répertoire contenant les fichiers de session (/tmp, par défaut, donc si /tmp est pas un lien vers une autre partition, cherche le système de fichier monté sur /tmp ou /). Si y'a noatime dans la liste entre parenthèses, c'est que la gestion de atime est désactivée.
 

 
Et les autres applications qui tournent sur le serveur n'utilisent jamais session_start(), avec le même répertoire pour les fichiers de session? (même si elles s'en servent pas, il est pas impossible que quelqu'un ait laissé un session_start() traîner...).
 
Essaie de changer session.save_path, avant de lancer la session, pour vérifier si c'est ça ou non (vérifie bien que tu pointes vers un répertoire dans lequel le serveur Web peut écrire).
 
Un autre problème possible, pour les serveurs always-on, c'est les scripts cron (qui sont exécutées automatiquement, notamment toutes les heures, par exemple), que certains administrateurs pourraient créer pour nettoyer le répertoire /tmp... enfin théoriquement, ces scripts sont censés voir large, pour pas supprimer de fichiers qui pourraient encore servir, mais on sait jamais... Changer session.save_path te permettra aussi d'éviter ça.

J'ai vérifié pour mount, j'ai pas noatime. Pour les autres applis, elles utilisent aussi les sessions mais y'en a au moins 2 qui utilisent session_name(). Je précise que les déconnexions sont pas dûes au fait que qq'un se connecte sur 2 applis et se déconnecte d'une ce qui entraînerait la déconnexion de l'autre appli. Ce n'est pas ça. Je précise que sur ce serveur y'a Mantis et MediaWiki. je ne sais pas si c'est applis ont un comportement "spécial" vis-à-vis des sessions. J'ai testé qu'en me déconnectant de mediawiki ça ne me déconnectait pas de l'intranet : c'est donc pas ça...
Pour le session path, sur l'ancien serveur, on n'avait pas ce pb et pourtant les sessions des applis étaient dans le même répertoire...

 
session_name() n'est utilisé que pour le nom du cookie et du paramètre de l'URL. Il n'est pas utiliser pour différencier les noms des fichiers de session. Les fichiers de session utilisent tous le préfixe "sess_", suivi de l'identifiant de session.
 

 
J'ai bien compris. Le problème, c'est que si plusieurs applications utilisent /tmp, pour les sessions, et qu'une des applications indique que la durée de vie des sessions est de 24 minutes, alors le garbage collector va nettoyer n'importe quelle session qui se trouve dans /tmp, peu importe qu'une autre application indique que la durée de vie des sessions est de 10 heures, puisque le garbage collector n'a aucun moyen de différencier les sessions de ces deux applications, si elles utilisent le même chemin pour les fichiers de session.
 
D'autre part, il est possible que le problème n'apparaisse pas tout le temps, puisque le garbage collector n'est lancé qu'avec une probabilité de 1%, par défaut (voir session.gc_probability et session.gc_divisor).
 

 
Peut-être que vous ne vous en êtes pas rendu compte, parce qu'il y avait moins de visites qu'avant? (si le garbage collector a une probabilité trop faible de se lancer, la durée de vie des session peut dépasser sans problème la durée de vie spécifiée... la durée de vie n'est vérifiée que par le garbage collector... s'il se lance que deux fois par jour, les sessions ne seront nettoyées que deux fois par jour, même si elles sont censées ne durer que 24 minutes...).
 
Sinon, j'en sais rien. Si vous avez changé de serveur, y'a peut-être eu un changement de configuration qui est passé inaperçu... (genre si vous n'avez pas réutilisé le même php.ini, il est possible que quelqu'un avait modifié le php.ini de l'ancien serveur, pour allonger la durée de vie des sessions, mais que ça n'a pas été fait sur le nouveau php.ini...).
 
 
En passant, j'ai relu http://www.php.net/manual/fr/ref.s [...] axlifetime, et ils précisent bien le problème de session.save_path. Et puis pour atime, ils disent qu'en fait, PHP utilise mtime, depuis PHP 4.2.3 (en le mettant à jour manuellement, comme si c'était l'atime, je suppose). J'avais lu un ancien rapport de bug, j'aurai mieux fait de revoir le manuel directement :)

Merci pour toutes ces précisions . Via phpinfos, je peux comparer le php.ini de l'ancien serveur et du nouveau. En ce qui concerne les sessions, c'est tout pareil sauf une nouvelle variable qui a fait son apparition (l'ancien serveur était en php4 et mysql 3.23, le nouveau est en php5 et mysql 5)
Registered serializer handlers = php php_binary
 
Je sais pas trop à quoi ça sert...

Pour le coup du GC et du session.save_path, si j'ai bien compris, en faisant un ini_set("session.save_path", "NouveauChemin" ); dans le fichier de conf de mon intranet, mes sessions seront stockées dans le nouveau chemin et je n'aurai plus mon pb?

 
Je suppose que le problème vient effectivement de là (enfin tu verras bien quoi ^_^;).
 
Encore une fois, oublie pas de régler ça avant de lancer la session, et de vérifier que le serveur peut écrire dans le répertoire que t'indiques.

up
 
t'as résolu ton problème ?
 
Perso, vu que ça ne marchait pas, j'ai mis ces valeurs dans la config apache du site en question, les variables sont bien setées mais aucun résultat.  
Je voudrais ne pas passer par le php.ini car ça modifierait le comportement de tous les sites.

Ha, il me semble que j'ai peut-etre trouvé.
La probabilité d'exécution du garbage collector est de session.gc_probability / session.gc_divisor  
Le session.gc_probability est à 0 par défaut.  
Le fait de changer cette valeur va faire prendre en compte le session.gc_maxlifetime  

Non, le fait de changer le chemin des sessions n'a pas résolu mon pb Faut dire que je l'ai mis dans un sous-répertoire du répertoire où se trouvent les autres sessions des autres applis. Je ne sais pas si ça joue. Je me demande quand même si la suppression de mes session n'est pas liée à la présence comme appli de MediaWiki ou Mantis.