OVH Community, votre nouvel espace communautaire.

Problème de persistance de sessions sur Mutu Pro


LordGG
19/09/2016, 12h14
Bon bah les gars, merci 1000 fois, je ne sais pas comment j'aurais trouvé sans tomber sur ce sujet. Je n'aurais perdu qu'une seule nuit à me prendre la tête sur la durée de mes sessions

C'est dommage que du côté d'OVH ça ne soit pas mieux géré, ou à défaut, que le moyen de contournement ne soit pas mieux documenté.

YmAn
14/07/2016, 23h45
@Coudr, désolé pour la réponse tardive, après vérification il semblerait que je rencontre toujours des problèmes de sessions, mais elle semble plus variable étrangement..

Pourtant j'ai bien suivi tes instructions.
Par contre j'ai une question, on est bien d'accord qu'il faut que je créé le dossier "sessions" au niveau du dossier "www" ?
J'ai modifié les XXX par le nom de mon FTP.

J'ai vu que tu indiquais que ton phpinfo(); est bien modifié, alors que moi la ligne : session.gc_maxlifetime est toujours par défaut 1440 (master et local value).

Si tu peux me confirmer que je m'y suis bien pris
Merci par avance !

---

Je me permets de modifier mon message, il semblerait que c'était un problème de droit sur le dossier sessions.

J'ai du le passer en 750 pour que des sessions puissent se créer dedans, tu as aussi du faire ça ?
D'ailleurs est-ce dangereux niveau sécurité ?

Par contre quand je regarde dans le dossier sessions, il y a fichier sess_* mais de taille 0, est-ce normal ?

Merci

---

Enfait ça venait de moi, j’appelais mal la fonction, du coup maintenant mes sess_* ne sont plus vide.
Maintenant il me reste plus qu'à voir si la session dure bien le temps que j'ai mis

---

Ça à l'air d'être bon, après des tests sur 2 jours la durée de session dure plus que 1440s
Merci beaucoup @Coudr

Coudr
12/07/2016, 23h15
Du coup ça a fonctionné ?

YmAn
07/07/2016, 19h12
Merci pour ces précisions @Coudr, je vais tester tout ça.

Coudr
07/07/2016, 18h17
Il faut paramétrer un autre dossier pour mettre les sessions, sinon ça ne marche pas.
C'est l’intérêt de l'instruction "noforcetmp", sinon les sessions vont dans ce dossier tmp qui est purgé par défaut au bout de 1440s/

Du coup voici mes parametres :

J'ai mis 2 instructions dans le .ovhconfig (je ne sais pas laquelle fonctionne du coup)
app.engine.flags=noforcetmp
app.engine.flags=noforcetm
Et pour le parametrage des sessions :

$dossier = "/home/XXXXX/sessions/";
ini_set('session.save_path', $dossier);
ini_set('session.gc_probability', 1);
ini_set('session.gc_maxlifetime', 30*24*3600);
session_set_cookie_params(30*24*3600);
session_start();

YmAn
07/07/2016, 00h09
Bonjour,

Je me permets de remonter ce sujet car je souhaiterais aussi modifier la durée de vie des sessions sur mon hébergement pro mutualisé.
J'aimerais augmenter la durée de vie des sessions.

J'ai essayé plusieurs propositions et aussi celles citées sur ce topic :
- en modifiant le fichier .ovhconfig en y ajoutant : app.engine.flags=noforcetmp
- en ajoutant dans mon index.php :
@ini_set("session.gc_maxlifetime","3600");
@session_set_cookie_params(3600);
etc..

Mais je n'arrive toujours pas à trouver la solution..

Quelqu'un peut-il m'aider et m'expliquer (si possible) comment modifier la valeur par défaut de session.gc_maxlifetime qui est à 1440 ?
Merci par avance.

Coudr
10/05/2016, 20h22
En tous cas, ça fonctionne à nouveau avec l'instruction app.engine.flags=noforcetmp
J'arrive bien à définir un autre dossier et donc avoir une durée de vie des sessions différente
Merci pour le patch

Coudr
22/04/2016, 13h05
Citation Envoyé par testeur115
c'est car c'est des cas un peu spéciaux avec des sessions a durée différentes sur le même hebergement (quoi que ça doit pas être si atypique que ça )
Dès lors qu'OVH présente ses offres comme permettant d'avoir plusieurs site et plusieurs domaines :
https://www.ovh.com/fr/hebergement-w...gement-pro.xml
https://www.ovh.com/fr/hebergement-web/multidomain.xml

On devrait s'attendre à pouvoir avoir plusieurs sites qui fonctionnent sans interactions ni perturbation entre eux non ?

- - - Mise à jour - - -

Bon du coup je vais essayer en modifiant le fichier .ovhconfig pour voir si effectivement ça résout mes problèmes

testeur115
22/04/2016, 12h50
Bon ça fonctionne avec noforcetm, du coup j'ai mis les deux tags pour si jamais c'est corrigé et que celui sans p ne marche plus après

testeur115
22/04/2016, 11h55
c'est car c'est des cas un peu spéciaux avec des sessions a durée différentes sur le même hebergement (quoi que ça doit pas être si atypique que ça )
apparemment en métant app.engine.flags=noforcetm dans le .ovhconfig tu peux modifier le session.save_path, du coup tu met un sous dossier différent selon tes sessions (longues, courtes)
J'ai pas pu testé la je suis pas chez moi

Coudr
22/04/2016, 11h55
Citation Envoyé par testeur115
En faite a la base ovh bloque la modif du session.save_path et avait mis en place un contournement pour ceux qui veulent en ajoutant une ligne dans ovhconfig. Mais comme tu le dis aucune info dans les guides, c'est du officieux.
Donc en fait Ludo et Vincent m'expliquent que mes sessions ne marchent pas parce qu'il y a des problèmes avec le dossier partagé /tmp
Et qu'il faut que je parametre le session.save_path (alors même qu'il a toujours été dis sur le forum que ce n'était pas recommandé)
Mais ce paramètre n'est pas pris en compte sur les mutus OVH, ce qu'ils ne me disent pas.
Mais il existe une solution de contournement qui nécessite un parametrage du .ovhconfig, solution officieuse et non documentée, mais qu'ils ne jugent pas nécessaire de m'exposer.
Et en même temps cette solution de contournement ne fonctionne plus.

J'ai juste passé des heures à faire des tests inutiles
J'ai un peu l'impression d'être pris pour un pigeon

En tous cas, merci à toi testeur115 parce que sinon je crois que je serais en train de chercher pour rien

- - - Mise à jour - - -

Citation Envoyé par Nowwhat
A chaque moment T t'as combien de sessions ouvertes avec ton site ?
Les Mutus d'OVH, ils gèrent des centaines des milliers (millions ?!) des sites - dont certains n'ont même pas des sessions - d'autres en gardent beaucoup à jour. Parmi eux, bien plus que 99 % sont très bien sur un Mutu.
Quoi faire avec le moins qu'UNE % qui reste .... ? Résonne à l'envers : OVH va t’il adapter un système qui marche pour 99 % ?
Un dédié n'est pas la réponse à tout, j'en conçoit bien (le mutu non plus )
Exiger que les serveurs soient "normalement" configurés, ou qu'à défaut les exceptions soient documentées, ça ne me parait pas déconnant.
Mais me laisser chercher pour rien, parce que ça vient des paramètres serveurs, c'est abusé

testeur115
22/04/2016, 11h42
Citation Envoyé par Coudr
Non mais je vois pas le lien entre les parametres du .ovhconfig et le dysfonctionnement du session.save_path

Il y a un paramétrage à réaliser ?
Il y a une doc là dessus ? Parce que je ne trouve rien dans les guides OVH qui concerne les sessions dans le .ovhconfig.

Si tel est le cas, ce serait sympa de m'en informer plutôt que me laisser faire des tests inutiles parce que ça ne peut pas fonctionner car il faut activer une fonction non documentée...
Depuis une semaine tu me recommandes des paramétrages qui ne marchent pas parce qu'il y a des bugs sur vos serveurs.
Ca commence un peu à me soûler cette histoire de sessions...
En faite a la base ovh bloque la modif du session.save_path et avait mis en place un contournement pour ceux qui veulent en ajoutant une ligne dans ovhconfig. Mais comme tu le dis aucune info dans les guides, c'est du officieux.

- - - Updated - - -

Citation Envoyé par Ludo.H
Bonjour @Coudr,

L'option dans l'.ovhconfig est:

app.engine.flags=noforcetmp

Mais pour le moment du a une erreur de typo elle ne fonctionne plus (en fait il faut mettre : app.engine.flags=noforcetm).
Cela va être patcher la semaine prochaine il me semble.

Cdt,
PAS AVANT ??????????????



edit : a mais ça marche si on enleve le p ?

Ludo.H
22/04/2016, 11h37
Bonjour @Coudr,

L'option dans l'.ovhconfig est:

app.engine.flags=noforcetmp

Mais pour le moment du a une erreur de typo elle ne fonctionne plus (en fait il faut mettre : app.engine.flags=noforcetm).
Cela va être patcher la semaine prochaine il me semble.

Cdt,

Nowwhat
22/04/2016, 11h31
Citation Envoyé par testeur115
Non mais la c'est la base d'un mutualisé que les sessions fonctionne correctement, si la réponse à tout est de prendre un vps autant arrêter complètement de vendre des mutualisé
A chaque moment T t'as combien de sessions ouvertes avec ton site ?
Les Mutus d'OVH, ils gèrent des centaines des milliers (millions ?!) des sites - dont certains n'ont même pas des sessions - d'autres en gardent beaucoup à jour. Parmi eux, bien plus que 99 % sont très bien sur un Mutu.
Quoi faire avec le moins qu'UNE % qui reste .... ? Résonne à l'envers : OVH va t’il adapter un système qui marche pour 99 % ?

Un dédié n'est pas la réponse à tout, j'en conçoit bien (le mutu non plus )

Coudr
22/04/2016, 11h06
Non mais je vois pas le lien entre les parametres du .ovhconfig et le dysfonctionnement du session.save_path

Il y a un paramétrage à réaliser ?
Il y a une doc là dessus ? Parce que je ne trouve rien dans les guides OVH qui concerne les sessions dans le .ovhconfig.

Si tel est le cas, ce serait sympa de m'en informer plutôt que me laisser faire des tests inutiles parce que ça ne peut pas fonctionner car il faut activer une fonction non documentée...
Depuis une semaine tu me recommandes des paramétrages qui ne marchent pas parce qu'il y a des bugs sur vos serveurs.
Ca commence un peu à me soûler cette histoire de sessions...

Ludo.H
22/04/2016, 10h24
Bonjour,

Le patch portera sur le bug de la prise en ocmpte des paramètres du .ovhconfig.
Pour ce qui est du session.gc_maxlifetime, c'est PHP pas OVH qu'il faut contacter.

Cdt,

Coudr
21/04/2016, 19h45
Citation Envoyé par Ludo.H
Le soucis est remonté (pour information edouard ne travail plus sur le mutu).
Un patch a été fait, il va être déployé sous peu
Un patch pour quel problème du coup ?
- Le dysfonctionnement du session.save_path ?
- Le fait que le session.gc_maxlifetime soit unique pour l'ensemble de l'hébergement (et pas propre à chaque session créée) ?

Coudr
21/04/2016, 13h55
Citation Envoyé par Nowwhat
Le dédie ..... ou VPS à 3 € par mois
Ainsi tu pourrais changer ton pseudo : plus besoin de "tester" le produit (d'OVH), tu pourrais te concentrer sur le vrai travail ..... (donc, finalement, t’es très gagnant)
Pour ma part je n'ai ni les compétence ni le temps d'assureur d'assurer l'exploitation d'une plateforme d'hébergement web.
C'est pas forcément beaucoup de boulot, mais configurer proprement, assurer les mises à jour et optimiser le fonctionnement c'est du temps.
C'est bien pour ça que je prend un "hébergement"

testeur115
21/04/2016, 12h16
Non mais la c'est la base d'un mutualisé que les sessions fonctionne correctement, si la réponse à tout est de prendre un vps autant arrêter complètement de vendre des mutualisé

Nowwhat
21/04/2016, 12h01
Citation Envoyé par testeur115
....... juste du bidouillage, enfin c'est la politique d'ovh de bidouiller
La solution : "maintenir un système qui est limité par nature" va toujours attirer des 'consommateurs' qui trouveront ces limites.
Ces mêmes limites sont très nécessaires pour que le système puisse continuer à exister.
Enlever toutes les limites, et tout va s'effondre.

Ce n'est pas très 'social' ni écolo (comme c’est le concept ‘Mutu’), ni autre chose, mais il existe une solution:
Coté finance : tu vas perdre.
Coté gains de temps : tu vas gagner énormément, car le concept "illimites" n'existe plus. Ou peut-être si : la seule limite qui existera dorénavant sera : toi.

Le dédie ..... ou VPS à 3 € par mois

Ainsi tu pourrais changer ton pseudo : plus besoin de "tester" le produit (d'OVH), tu pourrais te concentrer sur le vrai travail ..... (donc, finalement, t’es très gagnant)

testeur115
21/04/2016, 11h44
d'accord mais comme j'avais communiqué avec lui à l'époque, je me suis permis de lui récrire directement par mail dans notre conversation d'il y a 2 ans
Étonnant que depuis le temps il n'y ai pas de solution propre qui ai été mise en place..... juste du bidouillage, enfin c'est la politique d'ovh de bidouiller

Ludo.H
21/04/2016, 11h39
Bonjour,

Le soucis est remonté (pour information edouard ne travail plus sur le mutu).
Un patch a été fait, il va être déployé sous peux

Cdt,

Coudr
21/04/2016, 11h21
Merci

testeur115
21/04/2016, 11h18
bah a l'époque edouard avait mis en place un patch, mais apparemment ça ne fonctionne plus, je lui ai envoyé un mail, il m'a répondu qu'il remontait ça à l'équipe

Coudr
21/04/2016, 11h17
Je vois ça
C'est sérieusement un problème, d'autant que c'est non documenté
Ludo.H, un commentaire à ce sujet ?

- - - Mise à jour - - -

Du coup tu avais trouvé une solution de contournement ?
Et pour le session.save_path tu confirmes effectivement que ça ne fonctionne pas ?

testeur115
21/04/2016, 10h59
c'est ce que j'avais découvert et signalé a ovh a l'époque...

Coudr
21/04/2016, 10h57
Citation Envoyé par testeur115
?!
Sérieux ?
Si j'ai un session.gc_maxlifetime plus court dans un sous domaine, alors toutes les sessions ont cette durée de vie ?

J'ai un wordpress dans un sous-domaine, du coup c'est peut être lui qui parasite le session.gc_maxlifetime ?

testeur115
21/04/2016, 10h42
hé...... si

https://forum.ovh.com/showthread.php...l=1#post598945

Coudr
21/04/2016, 10h25
Citation Envoyé par testeur115
A tu un autre système sur ton site susceptible d'utiliser les sessions ? il est peut etre configuré avec un maxlifetime plus petit.
Non j'ai bien vérifié hier en scannant tout le site à la recherche d'autres utilisations des sessions.
De toutes façons, si j'ai un autre site sur le même hébergement (mais un autre nom de domaine) qui utilise également ses propres sessions avec des paramètres différents, ça ne vas pas perturber les sessions de mon site ?

testeur115
21/04/2016, 08h00
Pour ma part le session.gc_maxlifetime est bien pris en compte mais le plus petit écrase l'autre :/ avant j'arrivais avec le patch du support à faire cohabiter 2 maxlifetime différent mais ça ne fonctionne plus.
A tu un autre système sur ton site susceptible d'utiliser les sessions ? il est peut etre configuré avec un maxlifetime plus petit.

Coudr
21/04/2016, 07h54
Citation Envoyé par testeur115
Du coup, je me suis rendu compte que mes sessions ne fonctionnent plus.... avant j'avais 2 types de sessions des courtes et des longues, ça fonctionnait à peu près bien mis en part lors d'un changement de serveur web. Mais maintenant je me retrouve avec le soucis que j'avais il y a 2 ans, mes sessions courtes écrasent les longues.... et le patch mis en place à l'époque n'a plus l'air de fonctionner, bizarrement, il y a quelques semaines j'avais fait des tests et ça fonctionnait, donc apparemment c'est nouveau... OVH il y a eut un changement récemment ?
Je ne suis donc pas fou
En fait j'ai le sentiment que les "local values" pour les sessions ne sont pas prises en compte :
Les session.save_path, session.gc_maxlifetime sont ignorés au profit des parametres par défaut.
Du coup le sessions sont de toutes façons enregistrées dans le /tmp et les durées sont standards...

La Team OVH, est-ce que vous pourriez faire qq tests là dessus et/ou nous indiquer s'il y a des configurations spécifiques à réaliser pour pouvoir réutiliser les sessions correctement ? Je rappelle qu'auparavant, tout fonctionnait bien...

Coudr
21/04/2016, 07h48
Citation Envoyé par testeur115
Déja faut éviter de mettre le dossier dans www. il faudrait mieux le mettre a la même hauteur et moi à l'époque j'avais mis directement ça ;
Code PHP:
session_save_path($_SERVER['DOCUMENT_ROOT']."/../sessions"); 
J'ai testé aussi (et d'ailleurs c'était mon premier test) mais comme c'était la configuration suggérée par Ludo.H...
Mais ça ne marche pas plus

testeur115
21/04/2016, 07h11
Du coup, je me suis rendu compte que mes sessions ne fonctionnent plus.... avant j'avais 2 types de sessions des courtes et des longues, ça fonctionnait à peu près bien mis en part lors d'un changement de serveur web. Mais maintenant je me retrouve avec le soucis que j'avais il y a 2 ans, mes sessions courtes écrasent les longues.... et le patch mis en place à l'époque n'a plus l'air de fonctionner, bizarrement, il y a quelques semaines j'avais fait des tests et ça fonctionnait, donc apparemment c'est nouveau... OVH il y a eut un changement récemment ?

testeur115
20/04/2016, 21h23
ah je me rappel j'avais ajouté : app.engine.flags=noforcetmp dans le ovhconfig...... je l'ai toujours mais ça n'a plus l'air de marcher du coup.....

testeur115
20/04/2016, 20h43
Déja faut éviter de mettre le dossier dans www. il faudrait mieu le mettre a la même hauteur et moi à l'époque j'avais mis directement ça ;
Code PHP:
session_save_path($_SERVER['DOCUMENT_ROOT']."/../sessions"); 

EDIT : j'avoue ça marche pas lol. J'ai même testé mon système actuel, car le support m'avais dis de créer des sous dossiers dans le tmp pour avoir des sessions courtes et des sessions plus longues. Et les dossiers sont bien créés mais les sessions sont à la racine du tmp.

Coudr
20/04/2016, 20h09
Je comprends pas, ça ne marche pas plus
Si je paramètre un dossier personnalisé, il semble que celui ci n'est pas pris en compte car aucun fichier de sessions n'y est enregistré

Par exemple :
ini_set('session.save_path', '/home/yogatime/www/sessions/');
session_start();
echo "Dossier : ".ini_get('session.save_path')."
";
print_r( scandir(ini_get('session.save_path')) );
Cela m'affiche bien :
Dossier : /home/yogatime/www/sessions/
Array ( [0] => . [1] => .. [2] => test )
(J'ai mis un fichier "test" dans le dossier pour vérifier que je listais bien le bon dossier)

Mais aucun fichier de session...

Par contre, si je demande à afficher le contenu du dossier /tmp
foreach(scandir("/tmp") as $f){
if($f != "." && $f != ".."){
echo $f." - " . date("F d Y H:i:s.",filectime("/tmp/".$f));
}
}
J'obtient (entre autre) cette ligne qui contient la variable 4ad21aab15c586a6d0b5737068bc2020 contenu dans mon cookie PHPSESSID :
sess_4ad21aab15c586a6d0b5737068bc2020 - April 20 2016 20:05:42
(Evidemment j'ai lancé la page à 20h05, et si je fais un file_get_contents sur le nom du fichier, cela m'affiche bien les valeurs attendues des variables de sessions)

Donc le parametre ini_set('session.save_path', '/home/yogatime/www/sessions/') n'est pas pris en compte par le serveur...

Je n'y comprends donc plus rien

testeur115
18/04/2016, 21h34
c'était pour moi cette remarque, car je n'ai pas un site à la fréquentation "raisonnable"

Coudr
18/04/2016, 21h16
Je ne comprends plus rien.

J'ai toujours lu sur les forum OVH qu'il fallait conserver les paramètres OVH par défaut et ne pas spécifier de dossier d'enregistrement de session, justement parce que c'était mieux optimisé.
Est-ce que cela a changé ? Si oui, ce serait bien de prévenir les utilisateurs...

Par ailleurs, je vois pas en quoi un site à la fréquentation "raisonnable" ne pourrait pas supporter les requêtes.
Ca veut dire quoi :
Ce qu'y confirme ce que je disais : le mutu n'est plus une offre suffisante pour vous, un dédié/VPS serait plus adapté.
Il y a une limite de requêtes/fréquentation ? Si oui laquelle ?

Ludo.H
18/04/2016, 12h16
Bonjour,

Pas d'autre solution.

j'ai déjà essayé ça a l'époque et ovh a bloqué mon hebergement : Too much NFS request
Ce qu'y confirme ce que je disais : le mutu n'est plus une offre suffisante pour vous, un dédié/VPS serait plus adapté.

Cdt,

testeur115
18/04/2016, 11h24
Bonjour,

comme je l'ai dit, j'ai déjà essayé ça a l'époque et ovh a bloqué mon hebergement : Too much NFS request

Ludo.H
18/04/2016, 10h18
Bonjour,

Comme l'a dit Vincent, le plus facile est de mettre vos sessions dans votre "home" : /homez.xxx//www/sessions/*
Il est possible de mettres les sessions en base aussi, par contre attention aux latences.
Nous avions étudié la possiblité d'utilisé "memcache" (https://memcached.org/) par contre celui-ci n'est pas utilisable dans le mutu. Car il ne sépare pas les données par utilisateurs et donc tout le monde verait les données de tout le monde.

Cdt,

testeur115
17/04/2016, 21h08
Citation Envoyé par vcasse
Bonjour,

Votre soucis provient probablement de là.

/tmp est une partition situé sur chaque serveur web. En temps normal, vous êtes toujours redirigé vers le même serveur.
Mais lorsque votre site est trop chargé, ou que le serveur est trop chargé, votre site peut être redirigé sur un autre serveur. /tmp étant unique par serveur, vos sessions ne suivent pas.

Pour conserver les sessions, vous pouvez les stocker dans votre dossier personnel (/homez/xxx) si vous le souhaitez.

Cordialement,
Vincent
D'autres solutions ?

Coudr
14/04/2016, 20h33
Aucun changement
Je n'y comprends donc rien

Coudr
12/04/2016, 22h35
Je vais essayer en supprimant les session.gc_maxlifetime et session_set_cookie_params pour voir

testeur115
12/04/2016, 20h23
j'ai pas trop regardé les sessions en ce moment :/ pour les paramètres, j'ai rien modifié du coup je fais des simple session_start();

Coudr
12/04/2016, 20h12
Citation Envoyé par testeur115
bah je l'ai fait moi à un moment donné de mettre mes sessions dans mon dossier personnel, bah ovh m'a bloqué : Too much NFS request
Et tout fonctionne correctement en ce moment ?
Si oui quels sont tes paramétrages de sessions (ini_set, session_set_cookie_params, etc.) ?

testeur115
12/04/2016, 20h00
bah je l'ai fait moi à un moment donné de mettre mes sessions dans mon dossier personnel, bah ovh m'a bloqué : Too much NFS request

Coudr
12/04/2016, 19h39
Ah c'est étonnant, jusqu'alors les recommandations sur les forums concernant les hébergements OVH étaient de laisser ce dossier tmp optimisé par le filer et de ne pas paramétrer de dossier spécifique pour les sessions.
Cela aurait-il changé ?

Je vais tester en tous cas

vcasse
12/04/2016, 14h05
Bonjour,

Votre soucis provient probablement de là.

/tmp est une partition situé sur chaque serveur web. En temps normal, vous êtes toujours redirigé vers le même serveur.
Mais lorsque votre site est trop chargé, ou que le serveur est trop chargé, votre site peut être redirigé sur un autre serveur. /tmp étant unique par serveur, vos sessions ne suivent pas.

Pour conserver les sessions, vous pouvez les stocker dans votre dossier personnel (/homez/xxx) si vous le souhaitez.

Cordialement,
Vincent

Coudr
12/04/2016, 14h01
Aucun, j'ai laissé le paramètre par défaut (à savoir le dossier /tmp), comme conseillé.

vcasse
12/04/2016, 09h37
Bonjour,

Quel dossier utilisez vous pour stocker vos sessions ?
ini_set('session.save_path', ...)
Cordialement,
Vincent

Coudr
11/04/2016, 23h55
Problème toujours présent malheureusement
Personne n'a jamais rencontré la même situation ?
Est-ce que redéfinir un dossier pour les sessions + gc_probability à 1 pourrait permettre de résoudre le problème ?

Sinon est-ce une question à poser au support ou je risque de me faire bouler ?

Coudr
26/03/2016, 13h26
Session Support enabled
Registered save handlers files user memcache
Registered serializer handlers php_serialize php php_binary wddx

Directive Local Value Master Value
session.auto_start Off Off
session.cache_expire 180 180
session.cache_limiter nocache nocache
session.cookie_domain no value no value
session.cookie_httponly Off Off
session.cookie_lifetime 2592000 0
session.cookie_path / /
session.cookie_secure Off Off
session.entropy_file no value no value
session.entropy_length 0 0
session.force_path 1 1
session.gc_divisor 100 100
session.gc_maxlifetime 2592000 1440
session.gc_probability 0 0
session.hash_bits_per_character 4 4
session.hash_function 0 0
session.name PHPSESSID PHPSESSID
session.referer_check no value no value
session.save_handler files files
session.save_path /tmp /tmp
session.serialize_handler php php
session.upload_progress.cleanup On On
session.upload_progress.enabled On On
session.upload_progress.freq 1% 1%
session.upload_progress.min_freq 1 1
session.upload_progress.name PHP_SESSION_UPLOAD_PROGRESS PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.prefix upload_progress_ upload_progress_
session.use_cookies On On
session.use_only_cookies On On
session.use_strict_mode Off Off
session.use_trans_sid 1 1
Je note qu'il y a une master value et une local value.
Et la master value de session.gc_maxlifetime est assez courte.
Pensez vous que ça puisse venir de là ? (Je vais chercher également ce que c'est exactement ces 2 niveaux de parametrage)

romainovh
26/03/2016, 11h20
Salut,

Avec un php_info() tu auras une partie "Session", ça peut te donner des pistes.

Coudr
26/03/2016, 10h41
Bon, j'ai du mal à comprendre...
Hier soir, j'ai noté la valeur du cookie PHPSESSID : 4ad21aab15c586a6d0b5737068bc2020
J'ai également récupéré et affiché la valeur du fichier 4ad21aab15c586a6d0b5737068bc2020 qui se trouve dans le dossier /tmp (j'ai récupéré l'emplacement grâce à la fonction l'instruction ini_get('session.save_path') ).
Le fichier contenait assez logiquement la valeur de mes variables de sessions :
date_cours|i:1458984826;is_connecte|b:1;id|s:3:"XX X";statut|s:4:"root";nom|s:15:"XXXXXXXXX";
(J'ai anonymisé les données)

Ce matin, connexion perdue.
Mais le cookie est toujours là et il a toujours la même valeur 4ad21aab15c586a6d0b5737068bc2020.
Mais premier chargement de la page, le fichier est vide.
Il faut que je me reconnecte, pour qu'il reprenne des valeurs.

J'ai comme l'impression que le fichier a été purgé...
Est-ce possible ? Est-ce un problème dans mes parametrages qui entraine un passage du garbage collector ? Ou est ce qu'il y a des parametres par defaut à surcharger ?

Est-ce que l'on peut récupérer quelquepart la durée de vie d'une session et autres parametres du gc ?

Coudr
25/03/2016, 20h58
Bonjour

Depuis quelques temps, j'ai des pertes de sessions sur mon site sans que je n'arrive à me l'expliquer.

J'utilisais jusqu'alors une routine de connexion classique :
ini_set('session.gc_maxlifetime', 30*24*3600);
session_set_cookie_params(30*24*3600);
session_start();
Pour avoir une session de 30 jours grâce aux cookies.
Suivant les recommandations formulée sur ce même forum, je spécifie plus depuis longtemps le dossier des sessions ( ini_set('session.save_path', ...)

Néanmoins, mes sessions sont perdues généralement après plusieurs heures lorsque je reviens sur le site.
J'ai scanné mes cookies avec EditThisCookies, et le cookie PHPSESSID semble bien présent et avec une durée de vie suffisante.

J'ai passé pas mal d'heures à chercher en vain, et n'étant pas capable de dater depuis quand est présent ce problème, je me tourne vers le forum.
Je me demande donc si :
- ce serait mon instruction qui ne serait pas correcte ?
- les paramètre d'ovh qui pourraient générer cela (limitation de la durée de vie des sessions ? problème de persistance des sessions lors de changement de serveurs ?)
- des évolutions de php qui pourraient expliquer cela (je suis sous 5.5)
- autre ?

Merci par avance pour vos idées