Bonjour,
la question a surement deja été discuté, mais je n'ai rien trouvé de probant ici ou là.
j'ai un /home sur /dev/sda2
/dev/sda2 1,8T 1,7T 64G 97% /home
j'aimerais trouvé pourquoi c'est plein,
si je fait des du -hs * à la racine de /home
puis que je fait la somme des dossiers, j'arrive tout juste à 580Go occupé.
donc bien loin du 1.7To annoncé.
il n'y a pas de fichier caché
ce sont des dossiers de projet web gérés par virtualmin.
j'ai bien pensé à un fichier de log effacé mais pas refermé, mais je ne me souviens pas de la commande pour trouver lequel serait fautif
il est vrai que je pourrais rebooter le serveur qui tourne depuis 204 jours, mais il y a des services que je ne maitrise pas dessus.
si vous avez une idée.
# lsof ?
Posté par Obsidian . Évalué à 4.
Hello,
Comme ça, je dirais
lsof, sinon un petitls -l /proc/*/fd/*.[^] # Re: lsof ?
Posté par NeoX . Évalué à 3. Dernière modification le 24 octobre 2012 à 22:37.
je connaissais lsof avec un argument, pour savoir quel process utilise le fichier ou le peripherique,
mais il ne me serait jamais venu à l'esprit de le lancer sans pour avoir la liste de tout ce qui est ouvert.
en tout cas avec quelques grep je sors ca
si la 7e colonne c'est la taille, ca ferait 1,28To recuperable en arretant ces scripts et en les relancant
ce serait supercool ;)
[^] # Re: lsof ?
Posté par Obsidian . Évalué à 2.
C'est bien le cas, et les tailles semblent correspondre à ce que tu cherches : 1,28To + 587Go ≈ 1,7-1,8 To, « à une vache près » comme dirait Astier. Le numéro qui suit est l'inode.
Yapukafaukon,
[^] # Re: lsof ?
Posté par mike.simonson . Évalué à 1.
Et maintenant la question qui me taraude.
Comment on en est arrivé là ?
Je ne comprend pas bien le rapport avec le fichier effacé mais pas fermer.
En gros ma question c'est surtout comment on évite de se trouver dans des situations comme celle-là.
Merci d'avance pour vos réponses qui vont illuminer ma lanterne j'en suis sur.
[^] # Re: lsof ?
Posté par barret benoit . Évalué à 1.
On arrête tous les process (= services ou programmes) qui utilisent un fichier F avant d'effacer le fichier F.
…
C'est trop simple pour être ça ou… ça doit être trop tordu pour être évident ?
[^] # Re: lsof ?
Posté par Obsidian . Évalué à 3.
La clé du mystère, c'est que tu peux aussi les arrêter APRÈS ! Mais il faut penser à le faire.
[^] # Re: lsof ?
Posté par Obsidian . Évalué à 10.
C'est un grand classique de l'administration système qui te donne l'impression d'avoir de la « matière noire » sur ton disque dur. Lorsque tu effaces un fichier, celui-ci n'est réellement retiré du disque que lorsque plus aucun lien dur ne le référence ET lorsque plus aucun processus en cours d'exécution ne possède un handle ouvert le concernant. Si une de ces deux conditions n'est pas remplie, il continue d'exister tout-à-fait normalement et son i-node est toujours valide. Le système de fichiers fait automatiquement le ménage quand elles le deviennent. Créer un nouveau fichier portant le même nom n'a alors aucune incidence : son i-node sera différent et il s'agira bien d'un fichier distinct.
Heureusement que ça fonctionne ainsi d'ailleurs, sinon détruire un fichier suffirait à faire planter un processus. C'est aussi ce qui te permet de mettre tes bibliothèques à jour sans avoir à passer en mode dégradé : les processus existants continuent leur tâche comme si de rien était et tout nouveau processus lancé après la mise à jour référence le nouveau fichier.
Il arrive souvent que des processus qui tiennent un log deviennent fous et entrent dans une boucle infinie dans laquelle ils écrivent sans relâche la même ligne. Donc, le log grossit jusqu'à occuper tout l'espace. Quand on est tout d'un coup confronté à ça, le réflexe humain est de faire un find pour trouver les plus gros fichiers et quand on voit que le responsable est un seul gros fichier de log qu'on lit une fois l'an, on l'élimine en général aussi sec. Et là, « c'est le drame ». :-) Le fichier a bien disparu mais l'espace n'est pas libéré. Pire, il continue à fuir. Là, en principe, une partie substantielle de la communauté des admins envisagent une réinstallation complète, voire une cyber-attaque terroriste en provenance des antipodes.
Il suffit de terminer le ou les processus qui tiennent ce fichier ouvert, tout simplement. Voire même, lorsque c'est possible, leur demander gentiment de le refermer. Et là, miracle. On récupère d'un coup une quantité d'espace que même le BOFH n'aurait jamais osé annoncer.
[^] # Re: lsof ?
Posté par mike.simonson . Évalué à 1.
Donc en gros pour trouver ce genre de problèmes un petit coup de lsof et de awk derrière avec les options qui vont bien pour lister par taille.
On redémarre le processus qui utilise ce fichier de log (puisqu'on dirait que c'est surtout les logs qui sont concernés) et hop problème résolu.
c'est plus malin donc de d'abord stopper le processus, puis effacer son fichier de log que le contraire où on oublie de stopper le processus.
Merci
[^] # Re: lsof ?
Posté par Obsidian . Évalué à 2.
Il vaut mieux même commencer par faire un grep sur ceux qui sont marqués comme « (deleted) ». Même si c'est autorisé, il s'agit quand même dans la plupart des cas d'une irrégularité.
Ça va sans dire, mais personne n'efface volontairement un fichier de log sans arrêter le processus quand on ne sait pas ce que l'on fait. D'abord, un processus ne devrait pas garder un fichier ouvert en permanence. Ensuite, rien ne t'indique dans un ls ou un find si un fichier est actuellement utilisé ou pas. Ce genre de problème arrive justement lorsque l'on efface d'emblée un fichier sans savoir à quoi il sert.
À noter qu'il existe un deuxième cas, pourtant élémentaire, qui peut causer ce genre de surprise : les liens durs. Tout le monde aujourd'hui est habitué à coller des liens symboliques pour tout et n'importe quoi, et à délaisser l'usage des liens durs. Je pense que c'est principalement dû à un effet de mimétisme lorsque l'on provient d'autres systèmes où ce concept n'existe pas. Moralité : on tombe sur un gros fichier qui fait 2To, on l'efface et là, l'espace n'est pas libéré. Gros moment de solitude de l'admin débutant s'il ne pense pas à cette possibilité très simple.
[^] # Re: lsof ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Drôle de terme, en Unix on dit descripteur de fichiers non ?
[^] # Re: lsof ?
Posté par BFG . Évalué à 2.
À propos de ça justement, comme Google Chrome utilise plusieurs processus, cela complique sa mise à jour.
[^] # Re: lsof ?
Posté par NeoX . Évalué à 2.
j'ai vu avec l'utilisateur ces process,
une fois tuer et relancer, on a bien retrouver 1.2To d'espace libre
merci à toi obsidian,
je vais ajouter un
lsof -l | grep deleteddans mon monitoringSuivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.