Est-ce que ça ne concerne que mon serveur ou un problème sur d’autres ?
Sur un spip3 et extensions tout neuf, et sans plugins,
sur un serveur virtualisé chez Sivit :
Tous les formulaires fonctionnent, sauf les forums, en admin comme en privé.
Prévisualiser le message fonctionne.
Lorsqu’on clique sur “Message définitif : envoyer au site” ça mouline jusqu’à, soit :
une page blanche avec l’indication du cache d’admin jusqu’à 735.2 Mo
soit un Fatal error: Maximum execution time of 60 seconds exceeded in /home/web/afcinema.com/ftp/www/spip-svn/ecrire/inc/session.php on line 264
Si je reviens sur la page le message a en fait bien été posté.
Est-ce que ça ne concerne que moi, ou spip3/forum? Je ne sais pas quoi chercher en particulier ou quoi indiquer à l’hébergeur si ça le concerne ?
Une idée, une piste sur la particularité des cvt du forum.
**Merci.**
**A.**
NB : jamais eu ce problème sur le même serveur avec les forum en spip2. En local avec Mamp aucun problème avec la même version spip3.
Est-ce que ça ne concerne que mon serveur ou un problème sur d'autres ?
Ahhhh ! Je me sens moins seul tout à coup ... Exactement les mêmes symptomes. Je suis arrivé à quelques conclusions mais je ne suis pas sûr du tout de leur validité, j'ai posté ici mais sans réponse ...
En augmentant le niveau de log on se rend compte que le temps est passé dans un code qui gère les sessions; mon répertoire tmp/sessions est rempli de fichiers identiques avec des noms à rallonge. Pas de pb sur mon serveur de test, une différence notable est que sur le vrai serveur le système de fichiers est sous NFS, qui peut avoir ce genre d'effets.
Je vais essayer de reproduire le log correspondant et je le reposterai.
Ahhhh ! Je me sens moins seul tout à coup ... Exactement les mêmes
symptomes. Je suis arrivé à quelques conclusions mais je ne suis pas sûr
du tout de leur validité, j'ai posté ici mais sans réponse ...
En augmentant le niveau de log on se rend compte que le temps est passé
dans un code qui gère les sessions; mon répertoire tmp/sessions est
rempli de fichiers identiques avec des noms à rallonge. Pas de pb sur
mon serveur de test, une différence notable est que sur le vrai serveur
le système de fichiers est sous NFS, qui peut avoir ce genre d'effets.
Je vais essayer de reproduire le log correspondant et je le reposterai.
Voila, j'ai reproduit le problème. Le message se poste, il est en base et tout, on peut le voir dans l'espace privé comme public, mais le système ne rend pas la main et le même message se répète. J'ai mis la sortie ici :
(il y a des messages comme quoi iextra, notifications etc ne se chargent pas, mais les symptômes étaient exactement les mêmes avec un système vierge). J'ai mis aussi le contenu du tmp/sessions courant ici :
hello,
chercher les différences entre prod et local sous mamp (il y en a
forcemment une ) ...
à comparer : les versions de PHP : identiques ?
base mysql ou sqlite ?
la version exacte de spip pour essayer de reproduire ?
si tu as accès au fichier d'erreur apache aussi : y-a-t-il quelque
chose de remarquable ?
chercher les différences entre prod et local sous mamp (il y en a
forcemment une ) ...
Ouaip, il y en a une, c'est clair
à comparer : les versions de PHP : identiques ?
local = PHP de mac OS X = 5.3.6
prod = ce que m'a mis le CNRS = 5.1.6
(en particulier, _avant_ l'introduction de mysql_set_charset() mais c'est une autre histoire, la connexion db semble fermée au moment du bug.)
base mysql ou sqlite ?
MySQL les deux.
local = le MySQL de homebrew = 5.5.15
prod = ce que m'a mis le CNRS = 5.0.77
(mais a priori la partie db marche ? en tout cas le message est inséré.)
la version exacte de spip pour essayer de reproduire ?
svn://trac.rezo.net/spip/spip@1867 et extension forum 1.7.2 (mais je peux remplacer par HEAD si ça a une chance de résoudre, je sais qu'il ne faut pas mettre un site en prod sur une version svn mais maintenant c'est trop tard ... en tout cas j'ai guetté les commits, rien n'avait l'air de concerner ce problème à première vue).
si tu as accès au fichier d'erreur apache aussi : y-a-t-il quelque
chose de remarquable ?
(la ligne contient un appel à is_readable()) (pour ça que je suspecte un problème avec NFS - j'ai peur de jouer avec _SPIP_LOCK_MODE mais quand j'avais essayé ça n'avait pas changé grand chose ...)
Il y en a plein de paquets comme ça identiques, je n'en ai mis que 3. Pour info, au cas où ça aurait une influence, mon squelette ressemble à ça localement :
<div class="citer">Le comité de rédaction se
réserve le droit de modérer votre commentaire (par exemple
s'il estime qu'il n'a qu'un lien très éloigné avec
l'article auquel il est attaché, ou si le ton employé
n'est pas adapté à un débat serein).</div>]
[(#SESSION{id_auteur}|non)
<p>Pour participer à la discussion merci de <a
href="#URL_PAGE{perso}">vous identifier</a> (ou de <a
href="#URL_PAGE{inscription}">vous inscrire</a> si vous ne l'avez pas
encore fait).</p>
]
Dans inc/cvt_autosave.php il y a une boucle sur $GLOBALS['visiteur_session'] et dans le corps de cette boucle la globale en question est modifiée. Le comportement de php doit être non spécifié dans un tel cas, en particulier ça a l'air de pouvoir tourner en rond ... Suffit de faire une copie de la variable et de l'utiliser pour la boucle. Donc, dans inc/cvt_autosave.php ligne 83 :
- foreach($GLOBALS['visiteur_session'] as $k=>$v){
+ $tmp_globals = $GLOBALS['visiteur_session'];
+ foreach($tmp_globals as $k=>$v){
) ...