5

Linux : gestion des processus, qui ne libèrent pas de l’espace disque

Lorsque sur un serveur sous GNU/linux l’espace disque disponible est devenu critique, le premier réflexe est de supprimer les fichiers de log ou autres locale, qui prennent trop de place.
Mais si la suppression se fait en mode « sauvage », il se peut qu’aucun espace disque soit libéré !
Dans ce cas, il faut vérifier si des processus ont gardés ouvert ces fichiers, qui ont été supprimés. Ces processus deviennent des processus fantôme.

Vérification de l’espace disque

  • Vérification des partitions avec la commande df -h :

  • Ici dans mon cas sur ce serveur, il n’y a plus d’espace disque de disponible.

  • Mais si je vérifie avec la commande ncdu :

  • hummm, en faite d’après la commande ncdu, la partition racine n’occupe que 3.2Go de données !

    Identifier les processus

    Pour identifier les processus en cours d’exécution, qui n’ont pas libérer les fichier seront identifiés via la commande lsof avec comme argument +L1 :

    lsof +L1

    D’après le man de lsof :

    « +L1 » will select open files that have been unlinked.

    Pour revenir à mon cas :

    Les processus qui n’ont pas libérés les fichiers supprimés sont identifiés avec l’argument (deleted) en fin de ligne.
    Pour libérer de l’espace, il faut soit redémarrer le processus si c’est un démon ou le tuer.

    Une fois tous les processus redémarrés ou tués, on retrouve de l’espace disque sans avoir eu besoin de redémarrer notre système GNU/Linux. De toute façon, un Linux ne se redémarre jamais ;-)

Partager l'article :





fred

"Dire que l'on s'en fiche du droit à la vie privée sous prétexte qu'on a rien à cacher, c'est comme déclarer que l'on se fiche du droit à la liberté d'expression sous prétexte qu'on a rien à dire." Edward Snowden

5 commentaires

  1. Alors là, oui mais non !!!

    Ce qui me fait tiquer, c’est l’usage du « kill -9 », l’équivalent de l’arme nucléaire à la portée du 1er venu. C’est loin d’être une bonne idée, surtout dans l’optique de ne pas avoir à redémarrer un système sous GNU/Linux.
    Pour la faire courte (détails ici : http://doc.callmematthi.eu/BashIndex.html#kill_SIGKILL), un process qui reçoit un « kill -9 » va s’arrêter en l’état, sans fermer les fichiers ouverts, ni les sockets réseau, et sans libérer la RAM. Les processus arrêtés de cette façon vont consommer des ressources qui ne pourront être libérées que par un reboot. Concernant la RAM, même si c’est globalement « indolore » compte tenu de la quantité de RAM dispo, la RAM utilisée par le processus fermé via « kill -9 » ne sera pas libérée non plus. Si le « kill -9 » devient une habitude, les blocs de RAM non libérée vont se multiplier, limitant la quantité de RAM disponible (on encombre donc la RAM en tentant de décharger un peu le stockage…)
    De plus, si le processus qui « retient » des fichiers est un démon, on n’a pas besoin de le tuer sauvagement pour le forcer à les libérer : un restart suffit généralement, un « kill -1 » revient au même pour les tueurs en série.
    Et s’il faut VRAIMENT tuer un processus, pensez au « kill -15 », tout aussi efficace que le « kill -9 » et tellement plus propre ;-)

  2. Merci pour ce riche complément d’informations !
    j’édite l’article :-)

  3. Apres pour ce qui est de la ram rien n empeche de faire un petit ( en crontab ou pas )
    echo 3 > /proc/sys/vm/drop_caches
    en root

  4. Salut Fred, encore un article excellent et a la portée de tous, mais surtout comme toujours des trucs ou astuces qui n’ont l’air de rien mais vachement utile, merci.

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.