Project

General

Profile

Anomalie #3239

_CACHE_CONTEXTES_AJAX génère un dossier /tmp/cache/contextes qui grossit à l'infini

Added by RastaPopoulos ♥ almost 7 years ago. Updated about 2 months ago.

Status:
Fermé
Priority:
Haut
Assignee:
-
Category:
compilo
Target version:
Start date:
07/04/2014
Due date:
% Done:

0%

Resolution:
fixed
Navigateur:

Description

http://www.spip.net/fr_article5532.html

La fonctionnalité qui permet de déplacer dans un fichier les requêtes GET trop volumineuses que la sécurité Suhosin de PHP bloque, génère un dossier qui n'a pas l'air d'être renouvelé régulièrement. Du coup le dossier grossit en permanence jusqu'à atteindre des Gigas de données en dépassant le million de fichiers. C'est un bug dans le noyau de SPIP donc.

Là dans un site, j'avais plus de 6 Gigas dans 1 491 782 fichiers, et du coup il n'y avait plus d'inodes sur le disque. Et donc plus rien ne marchait.

patch.diff View - basculer en contexte ajax automatiquement sur longueur d’environnement trop grande. (3.05 KB) marcimat 🌻, 04/23/2020 03:06 PM

History

#1 Updated by cedric - almost 7 years ago

Pour moi le bug c'est d'avoir documenté et considéré cette feature comme stable alors qu'elle ne gère explicitement aucun mécanisme de purge ni de reconstruction (si on purge les hash et qu'un hash qu'on a plus sous la main se présente, comment reconstruire le contexte ?)

#2 Updated by marcimat 🌻 over 6 years ago

Juste un mot tout de même :
En SPIP 3, il ne faut pas déclarer cette constante. La solution intermédiaire qu'on utilise est de passer automatiquement par tmp/cache/contexte SI certaines conditions sont requises, au cas par cas. Particulièrement :
- si bug lors du décryptage du hash ajax (un bug sur une version de php) => on met le contexte en fichier cache
- si la longueur du hash dépasse la longueur autorisée pah suhosin (si présent) => on met le contexte en fichier cache.

De la sorte, ça limite grandement le nombre de fichiers créés dans ce cache (et c'est fait de façon automatique).

Mais… ça ne résout pas du tout le problème : ces fichiers restent en cache et ne se nettoient jamais, ce qui potentiellement peut créer le même problème signalé ici.

#3 Updated by cedric - over 6 years ago

  • Target version changed from 3.1 to 3.2

On ne purge pas parce que si le contexte est perdu on ne sait pas gerer l'erreur cote JS
Il faut donc :
1/ une gestion d'erreur côté JS pour quand le serveur ne sait pas repondre (on rejoue le hit sans ajax par exemple)
2/ purger ou plus simplement utiliser un nombre de slots limités - avec cache_set/cache_get par exemple

Dans l'attente je repousse...

#4 Updated by cedric - over 6 years ago

voir #2123

#5 Updated by marcimat 🌻 over 6 years ago

Pour ce point, et temporairement le temps d'une solution plus perenne, ça pourrait utiliser le même système que dans local/cache-vignettes : r21676

#6 Updated by RastaPopoulos ♥ 12 months ago

  • Priority changed from Normal to Haut

Et donc comme vu sur la liste, ça s'est reproduit 6 ans plus tard (entre temps le disque a dû être beaucoup augmenté par l'hébergeur et donc ça ne s'est pas vu pendant longtemps, mais fatalement ça revient).
Et cette fois avec 47Go… (et sûrement des millions, dizaines de millions, de fichiers).

@marcimat quand tu dis "la solution intermédiaire qu'on utilise" c'est qui "on" ? C'est désormais SPIP 3 qui fait déjà ça tout seul ? et donc ya pas besoin d'une autre constante pour faire ça "seulement quand il y a besoin" comme le disait Cédric sur la liste, puisque c'est déjà le cas ?

Sauf que sans la constante, yavait vraiment des pages qui marchaient pas, le site est en SPIP 3 depuis le tout début, donc c'est bien en SPIP 3 qu'il y avait des problèmes d'URL trop longues aussi. Donc c'est pas mis en cache automatiquement comme tu le décris non ? Je suis pas sûr d'avoir tout pigé.

(je mets en "haut" car c'est un bug qui lorsqu'il apparait, pète le système de fichiers, donc c'est gros quand même)

#7 Updated by marcimat 🌻 12 months ago

Une proposition est de basculer en cache fichier si la longueur d’url devient trop grande (en plus du cas de la présence de suhosin).
Ça ne corrige pas tout, mais ça limite les problèmes.
Un patch possible (qui enlève le test php 5.4 : en 3.3 c’est php 5.6 min) :

#8 Updated by RastaPopoulos ♥ 12 months ago

  • Status changed from Nouveau to En cours

Merci !
Donc comme vu, sous 2000 c'est forcément toujours bon partout à priori, alors qu'au-dessus, ça peut mais plus sûr, cela dépend des navs. Donc par défaut, en cache dès que c'est > 2000.

Va falloir tester ça, même si là évidemment en prod, c'est en 3.2.

Et aussi pour être clair pour la suite : ça va limiter, moins de choses mises en cache, seulement celles nécessaires, mais ça continuera d'augmenter indéfiniment. :)

#9 Updated by RastaPopoulos ♥ 6 months ago

Hello,
j'ai revidé à la main pour la dernière fois le 28 juillet (où ça en était à 40Go en 3 mois), et là aujourd'hui 9 octobre, ça en est à 33Go et ça replante le disque avec des erreurs d'écriture.

Est-ce que le patch de marcimat est inclus en 3.3 ? C'est quoi le mieux que j'ai à faire pour tester ce patch en production donc en 3.2 (forcément en production puisque c'est là que ça plante et qu'il y a plein de visites) ?

#10 Updated by cedric - 2 months ago

  • Target version changed from 3.2 to 3.3

a noter le patch https://git.spip.net/spip/spip/commit/46a1d0e71f806e5d02d58763f1d615437db98ca8 qui implémente donc ce que mentionnait @marcimat

Also available in: Atom PDF