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: - Mais si je vérifie avec la commande ncdu :
Ici dans mon cas sur ce serveur, il n’y a plus d’espace disque de disponible.
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 ;-)
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 ;-)
Merci pour ce riche complément d’informations !
j’édite l’article :-)
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
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.
Salut lm28,
content de te revoir ;-)