Bizarre, car SPIP n'est censé donner son nom définitif à ce fichier que
lorsqu'il a fini d'y envoyer ses données ; est-il possible que le fichier
soit "écrit" mais pas totalement envoyé sur le disque au moment où un autre
process apache demande à le lire ?? Si tu utilises une version assez
récente de SPIP (1.6 ou CVS), essaie de prendre la version CVS de
ecrire/inc_cache.php3 pour voir si ça continue...?
@ Perline <perline@perline.org> :
J'ai un message qui revient régulièrement :
Quand j'efface le fichier, le site revient, mais l'erreur ne tarde pas à revenir.
Message :
Parse error: parse error in ecrire/data/inc_meta_cache.php3 on line 89
Et ledit fichier à ladite ligne, qui est l'avant-dernière ligne, me donne, en ce qui concerne donc les dernières lignes :
Bizarre, car SPIP n'est censé donner son nom définitif à ce fichier que
lorsqu'il a fini d'y envoyer ses données ; est-il possible que le fichier
soit "écrit" mais pas totalement envoyé sur le disque au moment où un autre
process apache demande à le lire ??
Pourquoi pas, mais alors c'est curieux car c'est tout le temps, pas occasionnellement.
Et en plus, cahque fois que je m'en aperçois, je l'efface.
Si tu utilises une version assez
récente de SPIP (1.6 ou CVS), essaie de prendre la version CVS de
ecrire/inc_cache.php3 pour voir si ça continue...?
Sur quel lien je l'attrape la CVS ?
Je dois préciser que j'ai installé la même version sur tous mes sites en Spip, que j'en ai un autre géré chez le même hébergeur (altern) mais pas sur le même serveur et que je n'ai ce problème que sur celui-là.
C'est une piste ?
___________________________________________________
@ Perline <perline@perline.org> :
J'ai un message qui revient régulièrement :
Quand j'efface le fichier, le site revient, mais l'erreur ne tarde pas à revenir.
Message :
Parse error: parse error in ecrire/data/inc_meta_cache.php3 on line 89
Et ledit fichier à ladite ligne, qui est l'avant-dernière ligne, me donne, en ce qui concerne donc les dernières lignes :
Bizarre, car SPIP n'est censé donner son nom définitif à ce fichier que
lorsqu'il a fini d'y envoyer ses données ; est-il possible que le fichier
soit "écrit" mais pas totalement envoyé sur le disque au moment où un autre
process apache demande à le lire ?? Si tu utilises une version assez
récente de SPIP (1.6 ou CVS), essaie de prendre la version CVS de
ecrire/inc_cache.php3 pour voir si ça continue...?
huuum, si c'est bien ca le probleme, cela signifie qu'il y a dans spip
un probleme d'acces concurenciel.
Normalement il n'a pas pas bcp de probabilité d'acces concurentiel :
- cache activé en permanence, avec des délais tres grands,
- nombre peu important de visiteurs sur une grande partie des sites,
- auteurs d'un meme site pas toujours tres nombreux, ou pas forcement
tous en train de travailler en meme temps.
Il se peut tres bien que 2 requetes Web arrivent en meme temps,
les 2 activent la réecriture du cache, et les 2 partent a peu pres
en meme temps dans un cycle de rejeneration des fichiers, mais avec
un leger decalage.
Je suis le process 1 :
- je genere les scripts qui vont bien
- puis j'essaie de faire un include
- manque de chance, pendant ce temps, je suis intérompu par le time-slicing
(temp partagé)
- et le second process efface le fichier que je m'apprete dont faire un include.
et voila qui fait mal !!!
est-ce qu'un verrou a été prévu a cet effet ?
on pourrait tres bien mettre soit un verrou fichier, soit un verou par le
biais d'une valeur en base de donnée.
est-ce qu'un verrou a été prévu a cet effet ?
on pourrait tres bien mettre soit un verrou fichier, soit un verou par le
biais d'une valeur en base de donnée.
Ce sont vraiment des choses à discuter sur spip-dev, et pas ici ; cela dit,
je pense que la dernière modif que j'ai faite sur inc_meta.php3 corrige le
problème.
est-ce qu'un verrou a été prévu a cet effet ?
on pourrait tres bien mettre soit un verrou fichier, soit un verou par le
biais d'une valeur en base de donnée.
Ce sont vraiment des choses à discuter sur spip-dev, et pas ici ; cela dit,
je pense que la dernière modif que j'ai faite sur inc_meta.php3 corrige le
problème.
Et donc je redemande : Sur quel lien je l'attrape la CVS ?
----------
Perline (mailto:webmaitresse@lipietz.net)
Attachée parlementaire - relations avec la presse
d'Alain Lipietz (député européen, France, Les Verts)
"> Si tu utilises une version assez
>récente de SPIP (1.6 ou CVS), essaie de prendre la version CVS de
>ecrire/inc_cache.php3 pour voir si ça continue...?"
Oui, il fallait lire ecrire/inc_meta.php3
Et ensuite :
>"je pense que la dernière modif que j'ai faite sur inc_meta.php3 corrige le
>problème.
Alors, en résumé, je change quoi ?
ecrire/inc_meta.php3 (si tu es déjà en version 1.6 ou supérieure ; sinon il
faut que tu fasses une mise à jour complète en CVS)
J'étais en 1.6, j'ai donc changé les deux (dans le doute <:-))
Depuis hier tout va bien, y'a plus de parse erreur et tralala.
Je surveille, si ça revient, je préviens.
Merci beaucoup, mais je m'étonne toujours d'arriver à trouver des problèmes que jamais personne les autres ils ont....
Un don sûrement...
__________________________________________
At 10:44 30/08/2003 +0200, Fil wrote:
"> Si tu utilises une version assez
>récente de SPIP (1.6 ou CVS), essaie de prendre la version CVS de
>ecrire/inc_cache.php3 pour voir si ça continue...?"
Oui, il fallait lire ecrire/inc_meta.php3
Et ensuite :
>"je pense que la dernière modif que j'ai faite sur inc_meta.php3 corrige le
>problème.
Alors, en résumé, je change quoi ?
ecrire/inc_meta.php3 (si tu es déjà en version 1.6 ou supérieure ; sinon il
faut que tu fasses une mise à jour complète en CVS)
-- Fil
****Fin du message end - Signature****
Perline
Journaliste scientifique
Docteur es sciences-technologie-société
perline@perline.org - http://perline.org/
Ce message est couvert par le secret de la correspondance
(art. 226-15 et 432-9 du Code pénal)
********************************************