Aide - Recherche - Membres - Calendrier
Version complète : session_start() dans les logs d'erreurs
Forum osCommerce-fr > Adapter OsCommerce MS2 > Echanges développeurs
Havock
Bonjour,

Sur les fichiers log d'erreurs de mon nouveau serveur je viens de constater la présence de nombreuses lignes comme celles-ci :

Code
FastCGI: server "/fcgi-bin-php5-fpm" stderr: PHP message: PHP Warning:  session_start(): Trying to destroy uninitialized session in /home/*****EDITED***/includes/functions/sessions.php on line 95
FastCGI: server "/fcgi-bin-php5-fpm" stderr: PHP message: PHP Warning:  session_start(): Failed to decode session object. Session has been destroyed in /home/*****EDITED***/includes/functions/sessions.php on line 95


La ligne 95 de sessions.php correspond à :

Citation
session_start()


En dehors de ça le site marche normalement (navigation, passage de commandes ...).

Quelqu'un aurait une idée de la cause de ces messages d'erreur ?

Merci

SaphyraK
Hello Havock!




Je n'ai pas eu cette erreur depuis un bail,

mais quand je l'avais c'est sur d'anciens scripts php très peu maintenus par des auteurs tiers (ou mes anciens scripts développés y'a un bail)
Mon autre raison d'avoir ce genre d'erreurs c'est par inattention dans des scripts de tests en local,

Donc, pour en revenir à ce qui cause ces avertissements (qui pourraient possiblement induire en erreur quelque chose par la suite)..
En fait.. c'est surtout quand le gestionnaire de sessions de PHP est démarré, et qu'un script réessaies de la redémarrer une seconde fois (voir plus d'une fois..)



Alors.. cela amène à ce genre d'avertissements pas joyeux.



Le truc étant que vu que ton site fonctionne sans aucuns soucis, je suspectes donc très fortement le même cas de figure que celui que j'ai énoncé plus haut.

Tu peux tenter en local de tester un truc à la place de ce fameux session_start(); à ta ligne 95, remplace par:

Code
if ( !isset($_SESSION) )
{
  session_start();
  }


Tu devrais ne plus avoir ces erreurs.

Ce que tu dois aussi rechercher, c'est si tu n'a pas un autre session_start(); plus haut ou dans un autre fichier !




Voilà, en espérant que cela te soit utile, je te souhaite une excellente soirée!

Havock
Hello SaphyraK,

Quand tu dis :

Citation (SaphyraK @ 6 May 2016, 19:24) *
Le truc étant que vu que ton site fonctionne sans aucuns soucis, je suspectes donc très fortement le même cas de figure que celui que j'ai énoncé plus haut.


tu parles de ça ?

Citation (SaphyraK @ 6 May 2016, 19:24) *
Donc, pour en revenir à ce qui cause ces avertissements (qui pourraient possiblement induire en erreur quelque chose par la suite)..
En fait.. c'est surtout quand le gestionnaire de sessions de PHP est démarré, et qu'un script réessaies de la redémarrer une seconde fois (voir plus d'une fois..)
Alors.. cela amène à ce genre d'avertissements pas joyeux.


J'ai regardé et je n'ai pas trouvé de session_start(); parasite.

Le truc c'est que pour une autre partie de mon site j'utilise des sessions (pas avec le code oscommerce) sans soucis ni message d'erreurs.

Je pensais à un problème purement oscommerce (entre autre parceque mes sessions sont sauvées en base et que ma base n'est pas en utf8 et via ce post : http://stackoverflow.com/questions/3305184...ion-in-cakephp3 ) mais alors pourquoi n'ai-je pas de message d'erreurs pour les sessions coté admin du site ??

Tu n'as rien dans tes logs (vu que les patch OVH peuvent causer des comportements surprenants cf ton post http://www.oscommerce-fr.info/forum/index....howtopic=71495) ?
SaphyraK
Bonsoir Havock,


Pour ma part, avec le bug que tu cites (sur les sessions administratives que j'avais): http://www.oscommerce-fr.info/forum/index....showtopic=71495

C'était le contraire moi, c'était la zone administrative qui était impactée et non la zone boutique..

C'était assez surprenant..
Et pour le trouver, j'ai du monter une machine virtuelle LINUX (décidé de lancer du Debian Wheezy).
J'y ai configuré un serveur lamp de zéro: j'y compilé un php, apache et MySQL spécialement de par leur sources pour matcher à 100% la configuration identique du serveur qui posait problème avec les sessions..
(car il ne faisait ça sur aucunes de mes configurations locales, distantes ou autres.. (VPS, dédié, pas un seul avait ce comportement curieux..)
Ayant réussi à reproduire le problème, j'ai donc eu beaucoup plus de facilité d'en trouver la cause par la suite..
Le plus difficile, c'était de réussir à le reproduire..

L'environnement OVH n'étant pas tout-à-fait à l'identique d'une environnement purement LAMP sans aucunes configuration/ou ordre différents à la compilation...


=========

Pour en revenir à ton souci, là comme ça, sans rien voir, c'est chaud de t'aider, mais je vais tenter:
(1) Dans la page que tu m'a donné: il y a quelqu'un qui préconise de passer l'encodage de la base en utf8_general_ci, je pense que tu devrais essayer déjà ça (en local, cela va de soi)
(2) Toujours dans la page que tu m'as donné: il y a une autre personne qui propose de faire des manipulations plus ou moins identique mais que sur la table et champs des sessions stockées dans MySQL.
(2.a) Paramétrer son CHARACTER sur "utf8".
(2.b) Paramétrer son COLLATION sur "utf8_general_ci"

L'étape 1 comme 2 est à tester en serveur de développement local.


Fais déjà ça et tiens moi au courant !



=========

Sinon, j'ai aussi regardé (comme tu m'as demandé) les logs de nombreux sites oscommerce, je n'ai pas ces deux lignes d'avertissements, pas une seule fois..
Mais j'ai aussi décidé de ne pas passer mes bases en utf8 lors de la migration vers un PHP plus récent.
Je fais un encode utf8 au niveau de l'affichage des données plutôt.


Havock
Hello SaphyraK,,

Après examen attentif de mes logs, il semble que le problème vienne en fait d'un développement personnel. (Ce qui m'agace c'est qu'en local sous wamp tout fonctionne).

En résumé j'ai modifié la partie recherche du site avec jquery pour y ajouter des suggestions de produits. Quand un internaute rentre des lettres dans le moteur de recherche ; à partir de la 4 eme lettre, j'utilise jQuery.post() pour faire des requêtes dans la base et retourner des résultats éventuels dans un menu situé sous le champs de recherche. Tout fonctionne bien au niveau des résultats affichés, sauf que quand l'internaute entre un caractère comme à, é, è ... ça me balance l'erreur dans les logs.
Ca sent les histoire d'encodage de caractères à plein nez.
Mon site et ma base sont en Latin1. Jeu de caractères pour MySQL: UTF-8 Unicode (utf8). Interclassement pour la connexion MySQL utf8_general_ci. J'ai passé l'interclassement et le charset de la table sessions en UTF8. Pas de changement.

Je vais regarder si il n'est pas possible de spécifier un charset autre que l'UTF8 pour les requêtes faites avec jQuery.post()
Bonbec
Bonjour,

Citation (Havock @ 17 May 2016, 17:15) *
... (Ce qui m'agace c'est qu'en local sous wamp tout fonctionne).

Compare les phpinfo(); de ton wamp et de ton serveur, notamment au niveau session des fois que cela puisse te donner une piste.
Havock
Bonjour Bonbec smile.gif

Tout semble identique (mais il y a forcément une différence que je n'ai pas réussi à trouver).

Bon je vais bidouiller pour remplacer automatiquement les lettres avec accent dans mon formulaire de recherche et ça marchera ; mais j'aurais préféré comprendre le pourquoi de la chose biggrin.gif
Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'informations, la mise en page et les images, veuillez cliquer ici.
Invision Power Board © 2001-2024 Invision Power Services, Inc.