WordPress et le trop plein de fichiers sess_*

Date: 16/06/2011 | Catégories: Blog,Open-source,Planet-libre,Systeme,Web | Tags: ,,,,,

Hier, plusieurs lecteurs (merci à eux :)) m'ont signalés que le message suivant s'affichait en haut de mon blog (sous WordPress 3.1.3):

Warning: session_start() [function.session-start]: open(/var/lib/php5/sess_7cad11067bb359c89ee47b9e692e47bf, O_RDWR) failed: No space left on device (28) in/www/wp-content/plugins/twitconnect/twitconnect.php on line 95

Ce message n'apparaissait que pour les lecteurs non authentifiés et uniquement sur certaines pages. Dans une premier temps j'ai donc décidé de désactivé le plugin incriminé dans le message d'erreur (TwitConnect qui permet de s'authentifier sur le blog avec son compte Twitter). J'ai ensuite regarder l'espace disque de mon serveur sans voir de problème. C'est en allant regarder les fichiers dans le répertoire /var/lib/php5 que j'ai commencer à comprendre pourquoi le plugin en question n'arrivait plus à générer de fichiers de sessions PHP (les fameux fichier sess_*). Il y avait en effet plus de 200.000 fichiers de ce type dans ce répertoire. On arrivait donc en limite maximale du nombre de fichiers par sous répertoire sous GNU/Linux en ext3.

Le problème vient sûrement d'un des plugins que j'utilise qui doit créer ces fichiers de sessions sans jamais les purger. Je suspecte (sans avoi de confirmation) le plugin TwitConnect et j'ai donc ouvert un incident sur le forum officiel du plugin.

Pour ne plus avoir de mauvaises surprises dans le futur, j'ai donc mis en place dans la crontab root journalière une commande qui va effacer les fichiers de sessions de plus de deux jours:

find /var/lib/php5/ -type f -atime +2 -name 'sess_*' -exec rm -f {} \;

Si vous utilisez également le plugin WordPress TwitConnect, je vous conseille donc de jeter un oeil sur ce répertoire et le nombre de fichiers sess_*.

Pour obtenir le nombre de fichier dans ce répertoire il suffit de saisir la commande suivante:

sudo ls -l /var/lib/php5/ | wc -l

En journée (après la purge de la nuit) je tourne autour des 45.000 fichiers (environ 25 nouveaux fichiers par minutes, mais cela dépend du nombre de visites non authentifiées sur votre blog...).

  • Bien vu! Merci pour le tuyau.

    Encore un coup de ces xxx de spambots…

  • DarkNekros

    Je et conseille de regarder logrotate pour pouvoir faire une sauvegarde/compression de ces fichiers.
    « http://linux.die.net/man/8/logrotate »

    • Visiteur

      Intérêt de sauvegarder les vieux fichiers de session ? Aucun. Et les compresser les rend inutilisables si la session associée existait toujours.

  • Vi j’ai préféré te prévenir, pensant que c’était un problème d’espace afin que tu ne soit pas vite embêté.

    Par contre le nombre maxi d’inode dépend des paramètres que tu as saisi lors de la création de ton FS

    Par exemple sur mon serveur Zimbra qui a aussi une partition en ext3

    Inode count: 52480000
    Free inodes: 50394587

  • Le problème ne vient pas du tout du plugin, mais de la configuration de l’OS et/ou de PHP.

    session.gc_probability ne doit pas être à 0 dans le php.ini, c’est ce qui lance le garbage collector des sessions.

    D’ailleurs si tu regardes bien dans debian, il y a un cron pour ça.

    • Je suis sous Ubuntu 10.04 LTS et la variable session.gc_probability est à 100.
      Par contre j’ai bien le script cron en question mais qui ne doit pas être exécuté assez souvent…

  • Correction :
    find /var/lib/php5/ -type f -atime +2 -name ‘sess_*’ -exec rm -f {} \;

    (le \ à la fin si tu veux que ton exec fonctionne

    Crdlt

    Thom