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

Closed
opened 9 years ago by rastapopoulos · 18 comments
Owner

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.

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.
Owner

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 ?)

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 ?)
Owner

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.

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.
Owner

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...
Version cible mise à 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... **Version cible mise à 3.2**
Owner

voir #2123

voir #2123
Owner

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

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
Poster
Owner

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)

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)
Owner

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) :

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) :
Poster
Owner

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. :)
Statut changé à 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. :) **Statut changé à En cours**
Poster
Owner

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) ?

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) ?
Owner

a noter le patch 46a1d0e71f qui implémente donc ce que mentionnait `marcimat
Version cible mise à 4.0

a noter le patch https://git.spip.net/spip/spip/commit/46a1d0e71f806e5d02d58763f1d615437db98ca8 qui implémente donc ce que mentionnait `marcimat **Version cible mise à 4.0**
Owner

corrigé via 2b291c5690 et 3e6f39980c
Statut changé à Fermé

corrigé via https://git.spip.net/spip/spip/commit/2b291c56909af26b525d250bcc17df10fb1745b7 et https://git.spip.net/spip/spip/commit/3e6f39980c76a35b8a124f0051d640779e8cfb6a **Statut changé à Fermé**
Poster
Owner

J'ai l'impression que les deux commits qui corrigent cela ne sont pas très gros. Encore une fois comme 3.2 LTS, et que là c'est quand même un bug qui nique un peu le serveur en le remplissant à l'infini, est-ce qu'il ne faudrait pas backporter ça en 3.2 ?

J'ai l'impression que les deux commits qui corrigent cela ne sont pas très gros. Encore une fois comme 3.2 LTS, et que là c'est quand même un bug qui nique un peu le serveur en le remplissant à l'infini, est-ce qu'il ne faudrait pas backporter ça en 3.2 ?
b_b commented 1 year ago
Owner

+1 pour le backport en 3.2

+1 pour le backport en 3.2
Poster
Owner

Version cible mise à 3.2
Statut changé à En cours

**Version cible mise à 3.2** **Statut changé à En cours**
Owner

Reporté en 3.2 par 11821bec9 et 6c200052e

Reporté en 3.2 par 11821bec9 et 6c200052e
b_b commented 1 year ago
Owner

Topito, on ferme :)
Statut changé à Fermé

Topito, on ferme :) **Statut changé à Fermé**
Owner

Il faudra donc reporter 6a6422c067 aussi en 3.2

Il faudra donc reporter 6a6422c067da aussi en 3.2
b_b commented 1 year ago
Owner

@marcimat j'allais le faire, mais on n'a pas de fichier alertes.css.html en 3.2 je pense que https://git.spip.net/spip/spip/src/branch/3.2/prive/themes/spip/forms.css.html est le bon endroit où poser ça non ?

=> done f3ddc3f101

@marcimat j'allais le faire, mais on n'a pas de fichier `alertes.css.html` en 3.2 je pense que https://git.spip.net/spip/spip/src/branch/3.2/prive/themes/spip/forms.css.html est le bon endroit où poser ça non ? => done https://git.spip.net/spip/spip/commit/f3ddc3f101d07b07bdef013b7e73f486ce4a8a42
Sign in to join this conversation.
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.