Bonjour,
Emmanuel/ Déesse A. vient de mettre sur SPIP-Contrib un article qui contient
des correctifs de bug pour le nouveau compilateur de la dernière version
CVS.
RDV ici : http://www.spip-contrib.net/ecrire/articles.php3?id_article=639
Cordialement,
Jacques PYRAT - www.pyrat.net - Services de création de sites avec SPIP
Les nouvelles vont vite, même en période estivale !
En effet, comme expliqué dans le descriptif de la rubrique de cet article:
http://www.spip-contrib.net/ecrire/naviguer.php3?coll=57
nous sommes convenus de laisser reposer le CVS provisoirement.
Bon soleil à tous,
esj
'lo,
nous sommes convenus de laisser reposer le CVS provisoirement.
et les reports de bugs? on les faits toujours sur la liste? ou on attaque mantis?
Bon soleil à tous,
attention à votre peau quand même
Pierre
S'ils sont spécifiques à la CVS corrigée, sur le forum mentionné;
s'ils sont spécifiques à la 1.7.2 sur spip-dev.
esj
Salut,
je poste ici car je pense que le probleme est deja present dans la version
CVS :
Sur free, il semble que le systeme de lock à la création du cache plante
(enfin, ne passe pas pour etre plus juste ...) :
Fatal error: Maximum execution time of 15 seconds exceeded in
/var/www/free.fr/e/e/cheval.jeanmichel/inc-cache.php3 on line 203
Les repertoire de cache sont créés mais pas les fichiers ...
(j'ai verifié, l'attribut des repertoires est bien 755, on ne peut
apparement pas le modifier sur free)
j'ai posé quelques logs, il semble que ca bloque la (ligne 204) :
while (!flock($lock, LOCK_EX));
j'ai mis un log entre chaque ligne, le dernier à passer est juste avant,
celui juste après n'arrive jamais dans le log ...
j'ai ajouté un log dans la boucle, il s'arrete à la 44358 occurence, faute
de temps ...
qqun a une idée ?
@++
PS : sous windows pas de probleme pour le moment ...
j'ai posé quelques logs, il semble que ca bloque la (ligne 204) :
while (!flock($lock, LOCK_EX));j'ai mis un log entre chaque ligne, le dernier à passer est juste avant,
celui juste après n'arrive jamais dans le log ...j'ai ajouté un log dans la boucle, il s'arrete à la 44358 occurence, faute
de temps ...qqun a une idée ?
L'idée, c'est que flock n'est pas portable, c'est marqué noir sur blanc
dans la doc PHP.
> j'ai posé quelques logs, il semble que ca bloque la (ligne 204) :
> while (!flock($lock, LOCK_EX));
>
> j'ai mis un log entre chaque ligne, le dernier à passer est juste avant,
> celui juste après n'arrive jamais dans le log ...
>
> j'ai ajouté un log dans la boucle, il s'arrete à la 44358 occurence,
faute
> de temps ...
>
> qqun a une idée ?L'idée, c'est que flock n'est pas portable, c'est marqué noir sur blanc
dans la doc PHP.
Je croyais qu'il n'y avait qu'avec IIS que ca posait probleme (ISAPI) ou
avec les systemes de fichier en reseau (NFS).
J'ai vu passer des truc sur les vieux systemes genre win98 aussi ...
Free etant sous linux, je n'ai pas percuté de suite.
En fait, je viens de voir que le probleme a été signalé le 25/03/04 :
foncction flock, sleep ... désactivée sur free.
Heu sinon, quand je demandais une idée, c'etait plutot une rustine ou un
moyen de corriger ca...
Je vais deja faire une fonction spip_flock et faire des essais avec d'autres
methodes (il y a en plus un flag_flock detectant la presence de la fonction
mais non utilisé. Je ne suis pas sur qu'on puisse s'y fier).
Ca serait quand meme dommage d'aller placer un flag en base ...
L'idée, c'est que flock n'est pas portable, c'est marqué noir sur blanc
dans la doc PHP.
http://perl.about.com/cs/intermediateperl/a/022704_4.htm
serait-ce une bonne piste ?
Je croyais qu'il n'y avait qu'avec IIS que ca posait probleme (ISAPI) ou
avec les systemes de fichier en reseau (NFS).
Il y a des chances que certains hébergeurs mutualisés, dont Free,
utilisent des systèmes de fichiers en réseau (NFS ou NFS-like). En tout
cas je crois que c'est à la mode (centralisation du stockage et
répartition des ressources de calcul).
Heu sinon, quand je demandais une idée, c'etait plutot une rustine ou un
moyen de corriger ca...
Commenter la ligne "while(...) flock(...)" me semble une bonne idée.
D'une manière générale, il faut utiliser flock() le moins possible et
surtout pas d'une façon bloquante (i.e. éviter de boucler tant que
flock() ne renvoie pas true).
a+
Stephane LAURENT a écrit :
Ca serait quand meme dommage d'aller placer un flag en base ...
Antoine a écrit :
flock n'est pas portable, c'est marqué noir sur blanc dans la doc PHP.
Ces deux assertions sont tout le problème.
Au motif que certains systèmes n'ont pas un flock fiable,
les versions de Spip jusqu'à la 1.7.2 incluse ne l'utilisaient pas
et géraient le verrouillage au niveau du serveur SQL par un appel à GET_LOCK.
Malheureusement, cette solution a comme inconvénient que si le processus
qui appelle GET_LOCK meure avant d'appeler le RELEASE_LOCK symétrique,
on ne pourra plus demander ce verrou au serveur SQL qu'il faudra donc redémarrer.
Ce n'est pas le cas avec flock, car les systèmes d'exploitations libèrent automatiquement
toutes les ressources réservées par un processus au moment de sa disparition.
Le while(flock) a aussi l'avantage d'endormir le processus demandeur juste le temps nécessaire,
alors que le GET_LOCK nécessite un time_out arbitraire et non fiable.
Il faut aussi rappeler que si flock n'existait pas, aucun système d'exploitation multi-taches
n'existerait, on retournerait donc à l'informatique d'avant 1970 (naissance d'Unix),
c'est-à-dire même pas CP/M, l'ancêtre de l'ancêtre de w*nd*ws.
Il y a 2 stratégies par rapport à ça:
1. Soumettre Spip au nivelement par le bas imposé par qq hébergeurs,
notoirement connus pour ne s'adresser qu'au grand public,
donc dire que Spip ne s'adresse qu'aux amateurs,
et qu'il ne pourront compter Spip pour laisser le serveur SQL dans un état fiable;
2. Professionnaliser Spip en utilisant flock, en neutralisant son usage chez
les hébergeurs pour amateurs, et en signalant que Spip donnera le meilleur de lui-même ailleurs.
Pour moi, le choix est clair.
La méthode suggérée dans la doc Perl est une rustine qui n'est pas 100% fiable,
mais l'est autant que la méthode du verrou sur le serveur SQL.
On peut donc la prendre pour avoir un Spip au moins aussi fiable que le précédent
quel que soit l'hébergeur.
esj
Merci pour cette reponse Emmanuel.
Je proposerai bien une alternative : implementer les deux methodes dans Spip
et laisser un flag selectionner la bonne methode (par defaut l'ancienne de
Spip pour garder la compatibilité sur les serveurs installés).
Mais ca n'est pas evident à faire ... je vais regarder de plus près, j'ai un
petit site à faire (hebergé sur free) et j'aurai bien mis cette nouvelle
version ...
@++
Au motif que certains systèmes n'ont pas un flock fiable,
les versions de Spip jusqu'à la 1.7.2 incluse ne l'utilisaient pas
et géraient le verrouillage au niveau du serveur SQL par un appel à
GET_LOCK.
Malheureusement, cette solution a comme inconvénient que si le processus
qui appelle GET_LOCK meure avant d'appeler le RELEASE_LOCK symétrique,
on ne pourra plus demander ce verrou au serveur SQL qu'il faudra donc
redémarrer.
C'est faux. Quand une connexion MySQL détenant un lock tombe, le lock
est relâché. Tu peux vérifier en ligne de commande, en lançant deux
sessions MySQL séparées.
a+
Un exemple ne vaut pas démonstration. Sinon, parlons des exemples de pages blanches
envoyées par Spip qui ont été rapportés par Marc Quinton récemment sur cette liste,
ainsi que sur la liste des bugs il y a déjà longtemps et auxquels il n'a jamais été répondu.
Pour expliquer ces pages blanches, toute personne qui a un culture en programmation système se dit
"c'est parce qu'on a demandé à un serveur de gérer un verrou pour le client"
(au passage, si flock n'est pas fiable sous NFS, c'est justement parce que
c'est demander à un serveur de fichiers distants de gérer le verrou de son client).
Je suis donc enclin à mettre en doute ton affirmation:
pour qu'elle soit vraie, il faudrait que tous les systèmes accueillant MySQL
l'informent systématiquement de la disparition d'un processus. Ce n'est pas impossible en théorie,
mais ce n'est pas garanti en pratique, et c'est moins facile à vérifier que la présence de flock
sur une installation hors NFS.
esj
Je suis donc enclin à mettre en doute ton affirmation:
pour qu'elle soit vraie, il faudrait que tous les systèmes accueillant
MySQL
l'informent systématiquement de la disparition d'un processus.
La connexion au serveur MySQL se fait via une socket (Unix ou TCP, selon
la config). La disparition d'un processus client est donc naturellement
signalée par la fermeture à court terme de la connexion sur la socket.
et c'est moins facile à vérifier
que la présence de flock
sur une installation hors NFS.
Mais comment vérifie-t-on que l'installation utilise NFS ou non ? Et
comment vérifie-t-on qu'elle n'utilise pas un *autre* système que NFS
qui serait, lui aussi, incompatible avec flock() ?
D'autre part :
Il faut aussi rappeler que si flock n'existait pas, aucun système
d'exploitation multi-taches
n'existerait, on retournerait donc à l'informatique d'avant 1970
(naissance d'Unix),
c'est-à-dire même pas CP/M, l'ancêtre de l'ancêtre de w*nd*ws.
Affirmation à la fois inopérante et franchement farfelue, tu ne crois
pas ?
flock() n'est pas un préalable à la gestion de la concurrence entre
processus implémentée par mutex ou sémaphores.
La preuve par l'absurde, c'est que sinon, on ne pourrait pas faire de
synchronisation inter-processus sans avoir sous le coude un filesystem
"flock-compliant", ce qui serait pour le moins délirant (comment fait-on
avant même qu'aucun "vrai" filesystem soit monté ? comment fait-on sur
un système sans disque local où tout est monté en NFS ? sans compter
tous les systèmes multitâches qui n'ont pas l'API Unix/Posix et qui se
débrouillent sans la fonction flock()).
Du reste, sur la page suivante je lis :
http://www.unixprogram.com/cgi-bin/man.cgi?comd=2+flock
"HISTORY
The flock() function call appeared in 4.2BSD."
Ce qui est assez tardif par rapport à la prétendue simultanéité avec
l'apparition du multitâche (ou alors tu prétends que les systèmes BSD
avant 4.2 n'étaient pas multitâches...).
Donc, non seulement tu avances un argument inopérant (car basé sur une
affirmation d'historicité qui n'a aucun rapport avec le problème de
compatibilité discuté), mais en plus l'argument en question est
mensonger.
Quant à parler sans justification de "nivelage par le bas" à propos de
l'utilisation de NFS pour un hébergement mutualisé, c'est une
affirmation personnelle et gratuite. Du reste l'objectif de SPIP a
toujours été une compatibilité maximale, quel que soit le "nivelage par
le bas".
Bref, je suis d'accord que flock() a des avantages mais ce n'est pas la
peine d'inventer des justifications fantaisistes pour essayer de peser
d'un côté de la balance.
Pour résumer :
- flock() n'est pas portable, mais est 100% fiable (là où il fonctionne)
et a l'avantage de ne pas nécessiter MySQL
- la fonction MySQL GET_LOCK() est portable (là où il y a MySQL), est
100% fiable mais nécessite de se connecter à MySQL
a+
Antoine.
... RIEN sur les fameuses pages blanches parfois délivrées par Spip.
Pour moi, tout ma réimplémentation du cache est parti de là.
Cette absence de réponse devrait me dispenser de répondre sur les autres
points de mail, mais rapidement:
1. attendre la libération de la socket est long; ce n'est pas une solution;
2. la notion de verrou en informatique est bien antérieure à 4.2
(j'étais d'ailleurs trop gentil en évoquant CP/M: elle date des années 50);
3. ceux qui n'utilisent pas de verrou utilisent des sémaphores qui en sont
une version améliorée; ne perdons pas de temps à jouer sur les mots quand
ce sont des concepts qui sont en jeu.
Alors je ne vois pas ce qu'il y a de "mensonger" dans mon mail,
en revanche tout le monde a vu que tu évites soigneusement de répondre à certaines choses.
Emmanuel
... RIEN sur les fameuses pages blanches parfois délivrées par Spip.
Si tu veux discuter de ce problème (que personne n'a pu reproduire ni
étudier in situ), reprends le thread initial et évite de divertir les
autres discussions avec ça.
1. attendre la libération de la socket est long; ce n'est pas une
solution;
Alors, merci de quantifier "long". D'une part, en local sur une socket
Unix c'est généralement instantané. D'autre part les connexions TCP ont
traditionnellement un timeout assez court. En outre PHP ferme
automatiquement la connexion MySQL à la fin de l'exécution d'un script,
ce qui notifie immédiatement le serveur (TCP FIN). Comme enfin on prend
soin généralement de relâcher les verrous qu'on a posé (le contraire
étant une exception), cela rend la possibilité d'un problème extrêmement
théorique.
2. la notion de verrou en informatique est bien antérieure à 4.2
Ton argument est toujours fallacieux, ce n'est pas à force de le répéter
que tu vas le rendre opérant (par contre tu te rends fortement
désagréable avec ce genre de méthodes argumentaires). Je répète donc :
- D'une part l'existence de la notion de verrou au niveau du kernel
n'implique nullement l'existence de la fonction flock() dans l'API
fournie aux applications, et encore moins sa validité sur un filesystem
particulier. Pour quelqu'un qui parle sentencieusement de "culture en
programmation système" (on t'a déjà dit ce qu'on pensait des arguments
d'autorité sur cette liste ?), ce genre de confusion est gratiné.
- D'autre part l'argument d'historicité ("les verrous, ça existe depuis
toujours") n'a aucun effet argumentaire sur un problème de
compatibilité.
3. ceux qui n'utilisent pas de verrou utilisent des sémaphores qui en
sont
une version améliorée
Je ne vois pas toujours pas où est le rapport avec la présence ou
l'absence de la fonction flock(). Encore un argument spécieux.
; ne perdons pas de temps à jouer sur les mots
quand
ce sont des concepts qui sont en jeu.
Non, non, non. On ne parle pas d'un concept théorique (les verrous), on
parle d'une fonction particulière (la fonction flock). Si tu n'es pas
capable de faire la différence, c'est mal barré.
Alors je ne vois pas ce qu'il y a de "mensonger" dans mon mail,
Tout ce que j'ai pointé : ton mensonge grossier et prétentieux à propos
de la fonction flock() qui serait contemporaine de l'invention du
multi-tâches ; l'affirmation gratuite selon laquelle la centralisation
du stockage sur des volumes NFS consisterait en un "nivelage par le bas"
que SPIP n'a pas à prendre en considération.
Bref, l'étalage fatigant d'une connaissance trompeuse dans le but d'en
montrer à tout le monde et d'éviter qu'on cherche à vérifier la véracité
de tes arguments. Au lieu de continuer sérieusement la discussion qu'on
avait commencée sur le coeur du problème, tu pérores sans fin sur la
naissance des systèmes multi-tâches, et autres sujets oiseux.
en revanche tout le monde a vu que tu évites soigneusement de répondre
à certaines choses.
Ma parole ! En plus d'être spécialiste en programmation système
(mouarf), tu as aussi une formation de Grand Inquisiteur ?
a+
Le relecture de ce thread montre que c'est toi qui a quitté la discussion technique pour glisser sans raison dans l'attaque personnelle.
Ce bug dans ton fonctionnement a été reproduit de nombreuses fois; il serait temps de le corriger.
esj
Quoi de plus pratique que d'insulter les autres, et prétendre que c'est
eux qui ont commencé en premier (tm), quand on a été démasqué comme un
menteur prétentieux... Classique.
Houlala, j'aurai jamais du poser ma question ici moi !
Ca tire dans tous les coins et à balles réelle !
Pour reprendre un petit peu le fil du probleme il semble aujourd'hui que ni
l'une ni l'autre des solutions proposées ne soit satisfaisante à 100%
Alors, arretons de jouer sur les mots, un verrou sur un fichier ou en base
de données, tout le monde s'en fout pourvu que ca marche à tous les coups
quel que soit l'environnement.
Si j'ai une config avec un serveur SQL distant, peut etre derriere un
firewall ou d'autre bidules dans le genre, la solution de lock base de
données n'est pas raisonnable.
Si je suis sur Free, je n'ai pas droit au flock, mais le serveur SQL n'est
pas en local ... mais ca reste quand meme exceptionnel, on peut.
L'important à mon avis est de se proteger des boucles infinies et d'avoir un
systeme de rechange en cas de probleme avec le flock (qui est à mon avis la
meilleure solution si le filesystem le permet).
L'idéal serait de detecter l'option automatiquement, mais meme un petit flag
de configuration ferait tres bien l'affaire.
Emmanuel etant très réactif, c'est en cours ... il y a maintenant une
fonction spip_lock bien isolée donc 90% du probleme est reglé.
Il y a d'autres fonctions qui posent probleme chez Free, et cet hebergeur me
semble aujourd'hui incontournable pour Spip, alors ... je teste.
@++ (quand ca marchera !)
PS : la récrée est finie les enfants, on arrete de se chamailler et on va
faire ses exercices !
Houlala, j'aurai jamais du poser ma question ici moi !
Ca tire dans tous les coins et à balles réelle !
Pour reprendre un petit peu le fil du probleme il semble aujourd'hui que ni
l'une ni l'autre des solutions proposées ne soit satisfaisante à 100%
Alors, arretons de jouer sur les mots, un verrou sur un fichier ou en base
de données, tout le monde s'en fout pourvu que ca marche à tous les coups
quel que soit l'environnement.
Si j'ai une config avec un serveur SQL distant, peut etre derriere un
firewall ou d'autre bidules dans le genre, la solution de lock base de
données n'est pas raisonnable.
Si je suis sur Free, je n'ai pas droit au flock, mais le serveur SQL n'est
pas en local ... mais ca reste quand meme exceptionnel, on peut.
L'important à mon avis est de se proteger des boucles infinies et d'avoir un
systeme de rechange en cas de probleme avec le flock (qui est à mon avis la
meilleure solution si le filesystem le permet).
L'idéal serait de detecter l'option automatiquement, mais meme un petit flag
de configuration ferait tres bien l'affaire.
Emmanuel etant très réactif, c'est en cours ... il y a maintenant une
fonction spip_lock bien isolée donc 90% du probleme est reglé.
Il y a d'autres fonctions qui posent probleme chez Free, et cet hebergeur me
semble aujourd'hui incontournable pour Spip, alors ... je teste.
@++ (quand ca marchera !)
PS : la récrée est finie les enfants, on arrete de se chamailler et on va
faire ses exercices !
Pour reprendre un petit peu le fil du probleme il semble aujourd'hui que ni
l'une ni l'autre des solutions proposées ne soit satisfaisante à 100%
C'est bien ce que je disais... (cf. résumé à la fin de mon message
précédent)
pourvu que ca marche à tous les coups
quel que soit l'environnement.
C'est bien là le problème qu'on discute depuis le début, non ?
Si j'ai une config avec un serveur SQL distant, peut etre derriere un
firewall ou d'autre bidules dans le genre, la solution de lock base de
données n'est pas raisonnable.
C'est la config en question, dans ce cas-là, qui n'est pas raisonnable
du tout, car n'importe quelle requête sur la base (et il y en a souvent
: par exemple statistiques du site public) entraînera des latences
significatives. Dans une configuration "normale", le serveur SQL est
soit en local soit sur une machine du même LAN.
L'idéal serait de detecter l'option automatiquement, mais meme un petit flag
de configuration ferait tres bien l'affaire.
Non, il *faut* détecter le truc automatiquement. SPIP est destiné aux
non-informaticiens et il n'est pas question de demander au webmestre de
"choisir entre flock et MySQL GET_LOCK".
A chaque fois qu'il y a eu un conflit entre différentes méthodes (par
exemple au début entre .htaccess et l'authentification PHP), la
détection a été faite automatiquement. Cela ne doit pas changer.
a+