Lorsque la partition racine est saturée

Quelles conséquences ?

Vous n'arrivez plus à redémarrer Apache, les emails ne fonctionnent plus, vous n'arrivez plus à installer de nouveau logiciel, vous n'arrivez pas à appliquer de nouvelle release...

Comment s'en rendre compte
Avec une simple commande en SSH :

[user@nsXXXX user]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda1 1.9G 981M 887M 53% /
/dev/hda2 34G 3.8G 29G 12% /home
none 61M 0 61M 0% /dev/shm


ou dans Webmin ici : 'https://nsXXX.ovh.net:10000/fdisk/' ou (si votre Webmin n'est pas en SSL) : 'http://nsXXX.ovh.net:10000/fdisk/'

Les causes
On appelle partition système, / , slash, ou partition racine la partition ou est stocké le système de base. Les sites et tout ce qui doit être ajouté au serveur etant sur /home

Elles sont multiples :

  • backup de vos sites dans un repertoire autre qu'un sous-repertoire de /home,
  • décompression de grosses archives dans le répertoire HOME de root (/root),
  • installation de logiciel volumineux (serveur de jeux online par exemple) dans un répertoire appartenant à la partition système (/usr par exemple),
  • débordement de la queue d'email.

Solutions
  • Saturation accidentelle
Pour les 2 premiers cas, il suffit de deplacer les fichiers/répertoires dans un sous-répertoire de /home. Pour voir les fichiers les plus volumineux dans un repertoire, vous pouvez exécuter la commande suivante :

Head permet juste de n'afficher que les 10 plus gros fichier.

[root@nsXXXX root]# ls -lh --sort=size|head
total 20M
-rw-r--r-- 1 root root 2.6M mai 1 18:00 vim-common-6.1-18.7x.2.i386.rpm
-rw-r--r-- 1 root root 2.5M jui 22 10:15 mutt-1.4.1-1.src.rpm
-rw-r--r-- 1 root root 2.5M jui 22 10:33 mutt-1.4.1i-2mdk.src.rpm
-rw-r--r-- 1 root root 1.7M avr 9 2003 bind-9.2.1-1.7x.2.i386.rpm
-rw-r--r-- 1 root root 1.5M jui 18 14:25 tin-current.tar.gz
-rw-r--r-- 1 root root 1.4M avr 10 10:22 awstats-5.6-1.noarch.rpm
-rw-r--r-- 1 root root 1.1M jui 21 19:34 mutt-1.4.1-1.i386.rpm
-rw-r--r-- 1 root root 1.0M mai 1 18:00 vim-enhanced-6.1-18.7x.2.i386.rpm
-rw-r--r-- 1 root root 908k jui 23 16:28 mutt-1.2.5.1-1.i386.rpm



Ici, nous constatons que :

  • il y a 20Mo de fichier dans ce repertoire (ça ne prend pas en compte les sous-répertoires)
  • le fichier le plus volumineux est vim-common-6.1-18.7x.2.i386.rpm est qu'il pèse 2.6Mo

Pour résoudre le problème, nous allons déplacer les fichiers encombrant dans un répertoire sur /home. Visiblement, ce sont des .rpm et .tar.gz (des archives de logiciels). Il n'est pas du tout obligatoire de les concerver dans /root. Nous allons donc créer un répertoire sur /home pour les stocker.

[root@nsXXXX root]# mkdir /home/archives
[root@nsXXXX root]# mv *.tar.gz *.rpm /home/archives


Saturation à la suite de l'installation d'un (ou plusieurs) logiciel(s) volumineux
Vous avez par exemple installé un serveur HLDS (Half-Life Dedicated Server) dans /usr/local/game/hlds. Ce répertoire est sur la partition système, il faut donc le déplacer sur /home et créer un lien symbolique pour que le chemin reste valide.

Attention a bien stopper le serveur hlds avant l'opération !

[root@nsXXXX root]# mv /usr/local/game/hlds /home/
[root@nsXXXX root]# ln -s /home/hlds /usr/local/game/hlds


Bug de mod_gzip
Il arrive que mod_gzip ne supprime pas ses fichiers temporaires situé dans /tmp et que ceux-ci atteignent une taille importante (plusieurs Go). Pour s'en rendre compte :

[root@nsXXXX root]# ls -l /tmp/*.wrk
-rwx------ 1 nobody nobody 53695415 sep 30 00:10 _11831_132_33.wrk
-rwx------ 1 nobody nobody 0 sep 3 00:10 _12954_120_21.wrk
-rwx------ 1 nobody nobody 0 sep 7 00:10 _14733_110_11.wrk
-rwx------ 1 nobody nobody 0 sep 21 00:10 _16191_106_7.wrk
-rwx------ 1 nobody nobody 0 aoû 19 00:10 _16585_123_24.wrk
-rwx------ 1 nobody nobody 0 aoû 25 00:10 _16693_152_53.wrk
-rwx------ 1 nobody nobody 0 oct 5 00:10 _17282_110_11.wrk
-rwx------ 1 nobody nobody 0 sep 14 00:10 _17792_106_7.wrk
-rwx------ 1 nobody nobody 0 oct 7 00:10 _18056_108_9.wrk



Pour les supprimer :

[root@nsXXXX root]# rm -rf /tmp/*.wrk



Ce bug est connu, mais d'origine inconnue. Pour le moment, la seule solution pour l'éviter et de desactiver mod_gzip dans /httpd.conf. Recherchez la ligne mod_gzip yes et mettez à la place mod_gzip no. Redémarrer Apache ensuite ainsi :

[root@nsXXXX root]#/etc/init.d/httpd restart


Ce bug ne se produit que pour certains sites (sans doute dû a un script PHP ou CGI).

Queue de mails saturée
Voir le guide QueueQmailFull