[spip-dev] [SPIP Zone] erreur récurrente

Aaaah.
Je vois un peu le problème alors.
Il y a une concurrence entre le process qui vide le cache d’un côté (et supprime les répertoires vides depuis la 2.1), et celui qui essaye d’écrire dans un répertoire qui, paf, vient d’être supprimé !

Ça veut dire qu’il faut qu’on revoit la stratégie de purge alors, et indirectement la stratégie de rangement des caches sessionnés, qui a entrainé la creation de sous-sous dossiers en grand nombre, et le besoin de purger les dossiers aussi.
Cédric

…/…

vérifier les droits d’écriture#### Le système a rencontré une erreur lors de l’écriture du fichier ../tmp/cache/skel/html_b219ed595f9a0e886ed8818b87d7564a.php. Veuillez, en tant qu’administrateur du site, vérifier les droits d’écriture sur le répertoire tmp/cache/skel.

J’ai assaez fréquemment des erreurs de ce style depuis ma migration en 2.1 aussi sur un projet. De ce que j’ai pu voir, ce n’est pas un problème de quota non plus (je suis à moins de 21% de ma partition) mais plus de performances. En général, on est deux sur /ecrire, on fait chacun ses trucs, et pour peu que nous ayons besoin de vider plusieurs fois le cache pour X ou Y raisons, inmanquablement ca finit par plomber le système et par générer cette erreur.

En général dans ces cas là, on attend un peu, au besoin on vide les dossiers tmp et local par FTP et ça repart mais c’est vrai que c’est particuliers, surtout quand ca arrive en pleine démo client :stuck_out_tongue:

Aaaah.
Je vois un peu le problème alors.
Il y a une concurrence entre le process qui vide le cache d’un côté (et supprime les répertoires vides depuis la 2.1), et celui qui essaye d’écrire dans un répertoire qui, paf, vient d’être supprimé !

Ça veut dire qu’il faut qu’on revoit la stratégie de purge alors, et indirectement la stratégie de rangement des caches sessionnés, qui a entrainé la creation de sous-sous dossiers en grand nombre, et le besoin de purger les dossiers aussi.
Cédric

Moi je tourne sur une spip 2.09 pas sur une 2.1

c’est pareil aussi?

@Cerdic : Perso je mettais plus ca sur le dos de mon serveur (qui est, il faut bien le dire, une véritable merde) que sur le dos de Spip. Ce qui explique que je n’ai pas trollé la zone pour ce problème.

Cela dit, ton explication pourrait… expliquer bien des choses :stuck_out_tongue:

@nicolas : je sais pas pour la 2.0.9, j’avais ce genre d’erreur aussi mais ce n’était pas le même contexte, ma debian avait alors la facheuse habitude de passer en Read-Only sans prévenir. Mais j’ai réglé ce problème là depuis…

Ah non pas du tout, ce problème n’est pas susceptible de se produire en spip 2.0.9

Cédric

J’ai eu aussi ce problème récurrent après la mise à jour à la version 2.1.0… et je l’ai réglé en passant sur un serveur plus puissant (avant j’étais en mutualisé) ou les connexions simultanées sont en illimité.

<cedric.morin@yterium.com> a écrit dans le message de news:F3D710AE-D514-40AF-A0E4-09FB9E8D791F@yterium.com