Partition racine pleine sur serveur en release 2 OVH

J’aimerais aborder 2 petits « bugs » (ou plutôt 2 oublis) qu’on trouve sur la distribution phare chez OVH, la fameuse release 2. Deux oublis qui font que la partition racine de certains serveurs se remplit inexorablement et on voit alors souvent leurs propriétaires débarquer sur les forum OVH en quête d’assistance. Deux oublis qui font également dire à certains que la partition racine des serveurs en release OVH est beaucoup trop petite (ce en quoi ils ont partiellement tort, vous allez comprendre pourquoi), ce qui occasionne divers débats sur les forums et, indirectement, participe à la réputation quelque peu sulfureuse de cette distribution.

Je n’aborderai pas ici le partitionnement des disques durs en général et j’en arrive tout de suite à ce qui est bien souvent proposé par défaut sur les serveurs (notamment OVH). Il s’agit d’un partitionnement qui comprend, en simplifiant un brin, 2 partitions : une « petite » (la partition racine montée sur /) et une « grosse » (la partition destinée à accueillir les données et qui est bien souvent montée sur /home).

Je le répète, ce que je viens d’écrire ci-dessus est une simplification. Il n’en demeure pas moins qu’elle colle bien souvent à la réalité, en particulier en ce qui concerne les serveurs en release OVH (dont la plupart tournent avec le partitionnement par défaut puisque les utilisateurs de ce genre de serveurs s’amusent rarement à les répartitionner). On se retrouve donc avec une partition racine de quelques Go (ce qui est théoriquement suffisant puisqu’elle n’est censée n’accueillir que le système et pas les données) et tout le reste de l’espace disque est alloué à /home.

Le piège est alors de voir sa partition racine se remplir très vite car on y retrouve des données qui devraient évidemment se retrouver sur l’autre partition. Les cas les plus fréquents (sur les serveurs en général, hors release 2 donc) sont les bases de données (/var/lib/mysql), les logs (/var/log), etc. Tout un tas de choses qui peuvent devenir envahissantes à la longue puisqu’elles ont tendance à « grossir » avec le temps. Seulement sur la release OVH, ils ont prévu le coup ! Toutes les données et tous les logs ont été volontairement déplacés sur la « grosse » partition. On retrouve ainsi les bases dans /home/mysql, les logs dans /home/log, et ainsi de suite. Bien vu.

Bien vu … oui, sauf qu’ils ont malheureusement oublié deux bidules qui, avec le temps, présentent un risque d’encombrer la partition racine. Ces deux bidules, les voici :

Un fichier de log mail

Il s’agit de /var/spool/qscan/qmail-queue.log : un fichier de log tout bête mais sur lequel ne se trouve aucun logrotate. Il a donc tendance à enfler avec le temps, d’autant plus vite que le serveur est fortement sollicité en mail.

La solution : l’inclure dans le logrotate ou le déplacer sur /home (ou les deux à la fois). Pour le déplacer, rien de plus simple :

On coupe le mail
/etc/init.d/spamd stop
/etc/init.d/clamd stop
/etc/init.d/qmail stop
On déplace ce foutu fichier sur /home et on crée le lien symbolique qui va bien
mv /var/spool/qscan/qmail-queue.log /home/log/
ln -s /home/log/qmail-queue.log /var/spool/qscan/qmail-queue.log
On redémarre le mail
/etc/init.d/spamd start
/etc/init.d/clamd start
/etc/init.d/qmail start

Les logs binaires de réplication MySQL

En deux mots, ces logs enregistrent toute l’activité de MySQL et permettent par exemple, en cas de panne, de reconstruire les bases jusqu’à l’instant du crash (voir Google, notre ami à tous, si vous souhaitez creuser la chose). Ils sont précieux pour ceux qui font une utilisation avancée de MySQL … ce qui est rarement le cas des utilisateurs de release 2 dont la plupart ignorent tout de ces logs et ne s’en serviront jamais. Pourtant ils sont bien activés sur les serveurs en release et ils peuvent vite devenir énormes, surtout si votre base de donnée est fortement utilisée.

Purger les logs

Pour purger ces logs (qui, pour information, se trouvent ici : /var/run/mysqld), connectez-vous en root à MySQL en ligne de commande :

mysql -u root -p

(entrez le pass root MySQL, attention sur les serveurs en release 2 il est différent du pass root du système)

Vous obtenez alors un prompt du genre « mysql> » signifiant que vous êtes connecté à MySQL. Tapez la commande :

reset master;

Après quoi un « exit » suffit pour sortir de MySQL.

Désactiver les logs

Purger ces les logs de réplication, c’est bien (et cela va vraisemblablement vous libérer de la place) … mais si rien d’autre n’est fait, ils vont à nouveau se remplir inexorablement. Il reste donc à les désactiver. Pour ce faire, il suffit de :

Editer le fichier de config MySQL /etc/mysql/my.cnf et commenter la ligne suivante

(donc : ajouter une dièse en début de ligne)

#log-bin

Et redémarrer MySQL

/etc/init.d/mysql restart
Et si je veux les garder, ces logs ?

J’ajoute ce petit paragraphe suite aux commentaires de Thomas (voir ci-dessous) car il est vrai que certains pourraient avoir envie de conserveur ces fameux logs. Auquel cas il vous suffit d’appliquer la méthode décrite au début de ce billet concernant les logs mails et déplacer le répertoire /var/run/mysqld dans /home, par exemple dans /home/log. Attention à prendre soin de faire cette opération en ayant coupé le serveur MySQL. Soit à titre d’exemple :

/etc/init.d/mysql stop
mv /var/run/mysqld /home/log/
ln -s /home/log/mysqld /var/run/mysqld
/etc/init.d/mysql start

Sayé, c’est fini

Voilou, après ça l’espace disque de la partition racine de votre serveur ne devrait plus bouger d’un pouce ! 🙂 Mis à part peut-être lors de l’application des patches OVH pour mettre votre serveur à jour mais cela restera marginal.

20 réponses sur “Partition racine pleine sur serveur en release 2 OVH”

  1. Juste un mot pour vous remercier, ces explications super claires viennent de sauver la peau de mon serveur 😉

  2. Bonjour,
    Merci pour ces explications très claires et bien documentées.
    Une question, pourquoi ne pas proposer pour le deuxième problème la même solution que pour le premier ?
    Pourquoi ne pas déplacer les logs binaires de réplication sur /home ?
    Y a-t-il une raison à ce choix ? Ou simplement avez-vous considéré qu’un utilisateur de Release 2 n’a pas besoin de ces logs ?
    Thomas

  3. Vous avez parfaitement raison : il est tout à fait possible de déplacer ces logs dans /home. Il est ainsi également possible de ne pas les désactiver et de s’en servir si le besoin s’en fait sentir. Ne pas oublier cependant de procéder à la copie vers /home (et à la mise en place du lien symbolique) en ayant pris soin d’arrêter MySQL !

    A y regarder de plus près, on peut voir un brin de condescendance dans le billet ci-dessus, notamment lorsque j’écris que les utilisateurs de release 2 ignorent tout de ces logs et ne s’en serviront jamais. Il va de soi que je n’ai pas souhaité prendre les gens de haut, j’ai simplement décrit le fruit de mon expérience personnelle : il se fait que, de toutes les personnes que j’ai eu l’occasion d’aider sur des serveurs en release 2, aucune ne s’est jamais servie de ces logs. Aucune n’a souhaité disposer de ces logs de réplication permettant de reconstruire une base jusqu’au moment d’un crash potentiel. Les données de leurs bases n’étaient tout simplement pas assez critiques pour justifier le fait de conserver ces logs, toutes se sont contentées de la mise en place d’un backup quotidien de leurs données.

    Seulement voilà, ce n’est pas parce que moi je n’ai jamais croisé d’utilisateur de release 2 pouvant se permettre de perdre plusieurs heures d’activité MySQL que ce type d’utilisateur n’existe pas. Merci à vous de me le faire remarquer 🙂

  4. Bonjour,
    Il existe une autre catégorie d’utilisateurs de Release 2, à mon avis très majoritaire, qui ignorent l’existence de ces logs et seraient incapables de reconstruire une base avec, mais qui en cas de problème grave seront très contents de faire intervenir une personne ou une société compétente qui elle se servira de ces logs.
    Donc je pense que ce serait une bonne idée, dans le billet, de conseiller le déplacement.

  5. Pas d’accord sur le fait que ceux là constituent une part très majoritaire des utilisateurs de release 2 … mais d’accord sur le fait que le billet mérite d’être modifié. C’est chose faite 🙂

  6. Hop, mon problème de disque quasi plein est résolu en deux coups de cuillière à pot grâce à ton billet.
    Un grand MERCI à toi donc

  7. Bonjour,
    peut on supprimer purement et simplement ce fichier : qmail-queue.log
    quelles sont les conséquences ? si je le vide, ou si je le supprime ?
    Merci

  8. Le vider, pourquoi pas. Le supprimer, bof. L’idéal avec les logs reste tout de même de les conserver, on ne sait jamais. A pire, quand il prennent trop d’ampleur, logrotate est là pour faire le ménage et pour historiser.

  9. Bonjour Nico,
    J’ai la nette impression que ton billet devrait résoudre mon problème…
    Malheureusement, je ne suis pas webmaster, juste graphiste !
    Et je ne comprends pas où placer tous les codes dont tu parles.
    Si tu as 5 minutes, ça serait vraiment cool de prendre le temps de m’expliquer.
    Merci d’avance.

  10. Salut à tous,

    je viens déterrer ce vieux sujet 🙂

    Ce tuto est exactement ce que je cherchait, mais pour la release 3. ….

    J’ai mon disque plein aussi sur le rootfs, j’ai suivi toutes les instructions du tuto, mais sur la release 3, ça ne fonctionne pas.

    Tu peux m’aider nico ?

    Merci.

  11. Alors là effectivement c’est du déterrage. Pas grave 🙂

    Et de fait, les 2 astuces décrites ne s’appliquent qu’à la release 2 OVH et à aucun autre système (à moins d’une énorme coïncidence).

    D’une manière générale, pour voir ce qui occupe de la place sur un serveur, on commence par un étant des lieux des différentes partitions :

    df -h

    Après quoi on recherche par répertoire à grands renforts de « du ». Par exemple pour la racine :

    du -sh /*

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.