J'ai vu un truc bizarre ce soir alors que je pars à la chasse au gaspi
d'espace disque :
,----[ df -h ]
| Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
| /dev/hdc2 6,3G 6,1G 141M 98% /
| /dev/hdc3 3,0G 2,9G 147M 96% /home <== REMARQUEZ L'OCCUPATION
| /dev/hda3 86G 19G 63G 23% /mnt/hda3
| tmpfs 252M 0 252M 0% /dev/shm
| /dev/hda1 9,4G 7,4G 2,0G 79% /mnt/hda1
`----
si je regarde le contenu de /home
,----[ sudo du -ch --max-depth=1 /home ]
| 2,5G /home/seki
| 4,0K /home/ftp
| 1,5M /home/titi
| 2,5G /home
| 2,5G total
`----
On peut voir qu'il manque (à la louche) 400 Mo au total de /home, par
rapport à l'espace occupé indiqué par df.
Ce que confirme xdiskusage (lancé par root):
,----
| /home -------+--seki (2.444G)
| (2.993G) |
| +--(permission denied) (414.5M)
| |
| +--(free) (146.5M)
`----
Vues leurs tailles, les répertoires ftp et titi ne sont même pas listés par
xdiskusage.
Le problème c'est que je ne vois rien occupant 414 Mo dans /home :
,----[ sudo ls -la /home ]
| total 21
| drwxr-xr-x 5 root root 38 2004-12-02 00:38 .
| drwxr-xr-x 26 root root 776 2004-11-27 23:37 ..
| drwxr-xr-x 2 ftp nogroup 24 2004-01-28 01:13 ftp
| drwxr-xr-x 198 seki seki 12288 2004-12-02 00:27 seki
| drwxr-xr-x 24 titi titi 4096 2004-05-05 14:47 titi
`----
Question : où et comment trouver l'origine de ces 414 Mo qui sont en plus
inaccessibles à root ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
françois
Sebastien Kirche wrote:
Bonsoir,
Bonsoir, une piste comme ça, le man df indique:
Les valeurs sont indiquées en unités de 512 octets par défaut, mais si l'option -k est utilisée, l'unité est 1024 octets. Le format de sortie n'est pas défini si l'option -P n'est pas utilisée. Si le fichier n'est pas un fichier régulier, un répertoire, ou une FIFO, le résultat est imprévisible.
(Pour les blocs: c'est pareil pour du par défaut c'est du 512o).
Sebastien Kirche wrote:
Bonsoir,
Bonsoir,
une piste comme ça, le man df indique:
Les valeurs sont indiquées en unités de 512 octets par défaut, mais si
l'option -k est utilisée, l'unité est 1024 octets. Le format de sortie
n'est pas défini si l'option -P n'est pas utilisée. Si le fichier n'est
pas un fichier régulier, un répertoire, ou une FIFO, le résultat est
imprévisible.
(Pour les blocs: c'est pareil pour du par défaut c'est du 512o).
Les valeurs sont indiquées en unités de 512 octets par défaut, mais si l'option -k est utilisée, l'unité est 1024 octets. Le format de sortie n'est pas défini si l'option -P n'est pas utilisée. Si le fichier n'est pas un fichier régulier, un répertoire, ou une FIFO, le résultat est imprévisible.
(Pour les blocs: c'est pareil pour du par défaut c'est du 512o).
Sebastien Kirche
Le 2 déc 2004, françois vraute :
Bonsoir, une piste comme ça, le man df indique:
Les valeurs sont indiquées en unités de 512 octets par défaut, mais si l'option -k est utilisée, l'unité est 1024 octets. Le format de sortie n'est pas défini si l'option -P n'est pas utilisée. Si le fichier n'est pas un fichier régulier, un répertoire, ou une FIFO, le résultat est imprévisible.
(Pour les blocs: c'est pareil pour du par défaut c'est du 512o).
Ouiménon : j'ai bien passé des -h à mes commandes, ça exprime les unités de façon parlante pour le lecteur (ko, Mo, Go).
C'est moins précis que l'affichage des blocs, mais ça permet de se faire une idée immédiate, plutôt que se convertir des millions d'octets en Mo.
Sébastien Kirche
Le 2 déc 2004, françois vraute :
Bonsoir,
une piste comme ça, le man df indique:
Les valeurs sont indiquées en unités de 512 octets par défaut, mais si
l'option -k est utilisée, l'unité est 1024 octets. Le format de sortie
n'est pas défini si l'option -P n'est pas utilisée. Si le fichier
n'est pas un fichier régulier, un répertoire, ou une FIFO, le résultat
est imprévisible.
(Pour les blocs: c'est pareil pour du par défaut c'est du 512o).
Ouiménon : j'ai bien passé des -h à mes commandes, ça exprime les unités de
façon parlante pour le lecteur (ko, Mo, Go).
C'est moins précis que l'affichage des blocs, mais ça permet de se faire une
idée immédiate, plutôt que se convertir des millions d'octets en Mo.
Les valeurs sont indiquées en unités de 512 octets par défaut, mais si l'option -k est utilisée, l'unité est 1024 octets. Le format de sortie n'est pas défini si l'option -P n'est pas utilisée. Si le fichier n'est pas un fichier régulier, un répertoire, ou une FIFO, le résultat est imprévisible.
(Pour les blocs: c'est pareil pour du par défaut c'est du 512o).
Ouiménon : j'ai bien passé des -h à mes commandes, ça exprime les unités de façon parlante pour le lecteur (ko, Mo, Go).
C'est moins précis que l'affichage des blocs, mais ça permet de se faire une idée immédiate, plutôt que se convertir des millions d'octets en Mo.
Sébastien Kirche
Nicolas George
Sebastien Kirche wrote in message :
Question : où et comment trouver l'origine de ces 414 Mo qui sont en plus inaccessibles à root ?
Tu peux avoir un gros fichier supprimé mais encore ouvert par un processus. Je n'ai pas trouvé de bonne option à lsof ou fuser, mais une recherche dans /proc/*/fd des liens symboliques pointant vers un « foo (deleted) » (-lname '*deleted* avec GNU find) peut dire des trucs intéressants.
Sebastien Kirche wrote in message <85y8ghh6hn.fsf@obelix.seki.fr>:
Question : où et comment trouver l'origine de ces 414 Mo qui sont en plus
inaccessibles à root ?
Tu peux avoir un gros fichier supprimé mais encore ouvert par un processus.
Je n'ai pas trouvé de bonne option à lsof ou fuser, mais une recherche dans
/proc/*/fd des liens symboliques pointant vers un « foo (deleted) » (-lname
'*deleted* avec GNU find) peut dire des trucs intéressants.
Question : où et comment trouver l'origine de ces 414 Mo qui sont en plus inaccessibles à root ?
Tu peux avoir un gros fichier supprimé mais encore ouvert par un processus. Je n'ai pas trouvé de bonne option à lsof ou fuser, mais une recherche dans /proc/*/fd des liens symboliques pointant vers un « foo (deleted) » (-lname '*deleted* avec GNU find) peut dire des trucs intéressants.
françois
Sebastien Kirche wrote:
Le 2 déc 2004, françois vraute :
Bonsoir, une piste comme ça, le man df indique:
Les valeurs sont indiquées en unités de 512 octets par défaut, mais si l'option -k est utilisée, l'unité est 1024 octets. Le format de sortie n'est pas défini si l'option -P n'est pas utilisée. Si le fichier n'est pas un fichier régulier, un répertoire, ou une FIFO, le résultat est imprévisible.
(Pour les blocs: c'est pareil pour du par défaut c'est du 512o).
Ouiménon : j'ai bien passé des -h à mes commandes, ça exprime les unités de façon parlante pour le lecteur (ko, Mo, Go).
C'est moins précis que l'affichage des blocs, mais ça permet de se faire une idée immédiate, plutôt que se convertir des millions d'octets en Mo.
Sébastien Kirche
Je faisai plutôt référence à la derniere phrase mais bon, de toutes façon je ne pense pas que tu possèdes des fichiers exotiques:
j'ai trouvé ça d'intéressant, c'est pile ton cas, lire le file:
Les valeurs sont indiquées en unités de 512 octets par défaut, mais si
l'option -k est utilisée, l'unité est 1024 octets. Le format de sortie
n'est pas défini si l'option -P n'est pas utilisée. Si le fichier
n'est pas un fichier régulier, un répertoire, ou une FIFO, le résultat
est imprévisible.
(Pour les blocs: c'est pareil pour du par défaut c'est du 512o).
Ouiménon : j'ai bien passé des -h à mes commandes, ça exprime les unités de
façon parlante pour le lecteur (ko, Mo, Go).
C'est moins précis que l'affichage des blocs, mais ça permet de se faire une
idée immédiate, plutôt que se convertir des millions d'octets en Mo.
Sébastien Kirche
Je faisai plutôt référence à la derniere phrase mais bon, de toutes
façon je ne pense pas que tu possèdes des fichiers exotiques:
j'ai trouvé ça d'intéressant, c'est pile ton cas, lire le file:
Les valeurs sont indiquées en unités de 512 octets par défaut, mais si l'option -k est utilisée, l'unité est 1024 octets. Le format de sortie n'est pas défini si l'option -P n'est pas utilisée. Si le fichier n'est pas un fichier régulier, un répertoire, ou une FIFO, le résultat est imprévisible.
(Pour les blocs: c'est pareil pour du par défaut c'est du 512o).
Ouiménon : j'ai bien passé des -h à mes commandes, ça exprime les unités de façon parlante pour le lecteur (ko, Mo, Go).
C'est moins précis que l'affichage des blocs, mais ça permet de se faire une idée immédiate, plutôt que se convertir des millions d'octets en Mo.
Sébastien Kirche
Je faisai plutôt référence à la derniere phrase mais bon, de toutes façon je ne pense pas que tu possèdes des fichiers exotiques:
j'ai trouvé ça d'intéressant, c'est pile ton cas, lire le file:
http://www.culte.org/listes/linux-31/2000-08/ ==> "enigme occupation disque" pour le thread (il y a comme un problème pour lire la suite du thread)
manuel viet
In article , Sebastien Kirche wrote:
Bonsoir,
J'ai vu un truc bizarre ce soir alors que je pars à la chasse au gaspi d'espace disque :
Question : où et comment trouver l'origine de ces 414 Mo qui sont en plus inaccessibles à root ?
Peut-être juste une connerie, mais une fois, mon module pour zip ne s'est pas chargé, et la sauvegarde a atterri dans /mnt/zip, comme d'hab. Bien sûr, ensuite le zip a repris sa place, et je me suis retrouvé avec 100 Mo en vadrouille. Le temps que je comprenne qu'ils étaient /sous/ le montage...
-- (( Manuel Viet * mailto: (^.^) (")")
In article <85y8ghh6hn.fsf@obelix.seki.fr>, Sebastien Kirche wrote:
Bonsoir,
J'ai vu un truc bizarre ce soir alors que je pars à la chasse au gaspi
d'espace disque :
Question : où et comment trouver l'origine de ces 414 Mo qui sont en plus
inaccessibles à root ?
Peut-être juste une connerie, mais une fois, mon module pour zip
ne s'est pas chargé, et la sauvegarde a atterri dans /mnt/zip, comme
d'hab. Bien sûr, ensuite le zip a repris sa place, et je me suis
retrouvé avec 100 Mo en vadrouille. Le temps que je comprenne qu'ils
étaient /sous/ le montage...
--
(( Manuel Viet * mailto:manuel@m-viet.net
(^.^)
(")")
J'ai vu un truc bizarre ce soir alors que je pars à la chasse au gaspi d'espace disque :
Question : où et comment trouver l'origine de ces 414 Mo qui sont en plus inaccessibles à root ?
Peut-être juste une connerie, mais une fois, mon module pour zip ne s'est pas chargé, et la sauvegarde a atterri dans /mnt/zip, comme d'hab. Bien sûr, ensuite le zip a repris sa place, et je me suis retrouvé avec 100 Mo en vadrouille. Le temps que je comprenne qu'ils étaient /sous/ le montage...
-- (( Manuel Viet * mailto: (^.^) (")")
Sebastien Kirche
Le 2 déc 2004, françois a dit :
j'ai trouvé ça d'intéressant, c'est pile ton cas, lire le file:
Très intéressant en effet, surtout pour savoir que df et du ne se renseignent pas au même endroit.
Le 2 déc 2004, Nicolas George vraute :
Tu peux avoir un gros fichier supprimé mais encore ouvert par un processus. Je n'ai pas trouvé de bonne option à lsof ou fuser, mais une recherche dans /proc/*/fd des liens symboliques pointant vers un « foo (deleted) » (-lname '*deleted* avec GNU find) peut dire des trucs intéressants.
Effectivement, find /proc/*/fd -lname "*deleted*" me liste quelque chose, mais ça n'est pas trop parlant pour moi. ,----[ sudo find /proc/*/fd -lname "*deleted*" ] | find: /proc/19760/fd/4: Aucun fichier ou répertoire de ce type | /proc/23215/fd/1 | /proc/23215/fd/2 | /proc/3409/fd/1 | /proc/3409/fd/2 | /proc/3411/fd/12 | /proc/3415/fd/1 | /proc/3415/fd/2 | /proc/3416/fd/1 | /proc/3416/fd/2 | /proc/3417/fd/1 | /proc/3417/fd/2 | /proc/3494/fd/1 | /proc/3494/fd/2 | /proc/3543/fd/6 | /proc/3543/fd/7 | /proc/3549/fd/1 | /proc/3549/fd/2 | /proc/3550/fd/1 | /proc/3550/fd/2 | /proc/3551/fd/1 | /proc/3551/fd/2 | /proc/3552/fd/1 | /proc/3552/fd/2 | /proc/3553/fd/1 | /proc/3553/fd/2 | /proc/3554/fd/1 | /proc/3554/fd/2 | /proc/3555/fd/1 | /proc/3555/fd/2 | /proc/3556/fd/1 | /proc/3556/fd/2 | /proc/3563/fd/1 | /proc/3563/fd/2 | /proc/4144/fd/1 | /proc/4144/fd/2 | /proc/952/fd/11 | /proc/952/fd/12 | /proc/952/fd/14 | /proc/952/fd/15 | find: /proc/self/fd/4: Aucun fichier ou répertoire de ce type `---- Qu'est-ce que ces chiffres peuvent m'apprendre ?
Par contre un bête lsof | grep /home me liste entre autres un certain nombre de lignes «/.xsession-errors (deleted)». Fichier qui de mémoire faisait quelques centaines de Mo (!)[1].
Mais je l'ai supprimé en urgence il y a quelque temps avant de voir les erreurs à l'intérieur (pas mal d'applications dont le courier râlaient de ne plus avoir d'espace dans mon home) et pour le moment il n'est pas réapparu. Ça pourrait donc venir de là...
Faudrait que je redémarre X pour voir si la place se libère.
Footnotes: [1] Le fichier a eu le temps de grossir alors que mon uptime en est à 49 jours et que X n'a planté (shooté par le noyau pour allocation mémoire anarchique) que 2 fois. Faudrait que je prenne du temps pour voir l'appli X qui a des problèmes. Ça serait plus sain.
Sébastien Kirche
Le 2 déc 2004, françois a dit :
j'ai trouvé ça d'intéressant, c'est pile ton cas, lire le file:
Très intéressant en effet, surtout pour savoir que df et du ne se renseignent
pas au même endroit.
Le 2 déc 2004, Nicolas George vraute :
Tu peux avoir un gros fichier supprimé mais encore ouvert par un
processus. Je n'ai pas trouvé de bonne option à lsof ou fuser, mais une
recherche dans /proc/*/fd des liens symboliques pointant vers un « foo
(deleted) » (-lname '*deleted* avec GNU find) peut dire des trucs
intéressants.
Effectivement, find /proc/*/fd -lname "*deleted*" me liste quelque chose,
mais ça n'est pas trop parlant pour moi.
,----[ sudo find /proc/*/fd -lname "*deleted*" ]
| find: /proc/19760/fd/4: Aucun fichier ou répertoire de ce type
| /proc/23215/fd/1
| /proc/23215/fd/2
| /proc/3409/fd/1
| /proc/3409/fd/2
| /proc/3411/fd/12
| /proc/3415/fd/1
| /proc/3415/fd/2
| /proc/3416/fd/1
| /proc/3416/fd/2
| /proc/3417/fd/1
| /proc/3417/fd/2
| /proc/3494/fd/1
| /proc/3494/fd/2
| /proc/3543/fd/6
| /proc/3543/fd/7
| /proc/3549/fd/1
| /proc/3549/fd/2
| /proc/3550/fd/1
| /proc/3550/fd/2
| /proc/3551/fd/1
| /proc/3551/fd/2
| /proc/3552/fd/1
| /proc/3552/fd/2
| /proc/3553/fd/1
| /proc/3553/fd/2
| /proc/3554/fd/1
| /proc/3554/fd/2
| /proc/3555/fd/1
| /proc/3555/fd/2
| /proc/3556/fd/1
| /proc/3556/fd/2
| /proc/3563/fd/1
| /proc/3563/fd/2
| /proc/4144/fd/1
| /proc/4144/fd/2
| /proc/952/fd/11
| /proc/952/fd/12
| /proc/952/fd/14
| /proc/952/fd/15
| find: /proc/self/fd/4: Aucun fichier ou répertoire de ce type
`----
Qu'est-ce que ces chiffres peuvent m'apprendre ?
Par contre un bête lsof | grep /home me liste entre autres un certain nombre
de lignes «/.xsession-errors (deleted)». Fichier qui de mémoire faisait
quelques centaines de Mo (!)[1].
Mais je l'ai supprimé en urgence il y a quelque temps avant de voir les
erreurs à l'intérieur (pas mal d'applications dont le courier râlaient de ne
plus avoir d'espace dans mon home) et pour le moment il n'est pas réapparu.
Ça pourrait donc venir de là...
Faudrait que je redémarre X pour voir si la place se libère.
Footnotes:
[1] Le fichier a eu le temps de grossir alors que mon uptime en est à
49 jours et que X n'a planté (shooté par le noyau pour allocation
mémoire anarchique) que 2 fois. Faudrait que je prenne du temps pour
voir l'appli X qui a des problèmes. Ça serait plus sain.
Très intéressant en effet, surtout pour savoir que df et du ne se renseignent pas au même endroit.
Le 2 déc 2004, Nicolas George vraute :
Tu peux avoir un gros fichier supprimé mais encore ouvert par un processus. Je n'ai pas trouvé de bonne option à lsof ou fuser, mais une recherche dans /proc/*/fd des liens symboliques pointant vers un « foo (deleted) » (-lname '*deleted* avec GNU find) peut dire des trucs intéressants.
Effectivement, find /proc/*/fd -lname "*deleted*" me liste quelque chose, mais ça n'est pas trop parlant pour moi. ,----[ sudo find /proc/*/fd -lname "*deleted*" ] | find: /proc/19760/fd/4: Aucun fichier ou répertoire de ce type | /proc/23215/fd/1 | /proc/23215/fd/2 | /proc/3409/fd/1 | /proc/3409/fd/2 | /proc/3411/fd/12 | /proc/3415/fd/1 | /proc/3415/fd/2 | /proc/3416/fd/1 | /proc/3416/fd/2 | /proc/3417/fd/1 | /proc/3417/fd/2 | /proc/3494/fd/1 | /proc/3494/fd/2 | /proc/3543/fd/6 | /proc/3543/fd/7 | /proc/3549/fd/1 | /proc/3549/fd/2 | /proc/3550/fd/1 | /proc/3550/fd/2 | /proc/3551/fd/1 | /proc/3551/fd/2 | /proc/3552/fd/1 | /proc/3552/fd/2 | /proc/3553/fd/1 | /proc/3553/fd/2 | /proc/3554/fd/1 | /proc/3554/fd/2 | /proc/3555/fd/1 | /proc/3555/fd/2 | /proc/3556/fd/1 | /proc/3556/fd/2 | /proc/3563/fd/1 | /proc/3563/fd/2 | /proc/4144/fd/1 | /proc/4144/fd/2 | /proc/952/fd/11 | /proc/952/fd/12 | /proc/952/fd/14 | /proc/952/fd/15 | find: /proc/self/fd/4: Aucun fichier ou répertoire de ce type `---- Qu'est-ce que ces chiffres peuvent m'apprendre ?
Par contre un bête lsof | grep /home me liste entre autres un certain nombre de lignes «/.xsession-errors (deleted)». Fichier qui de mémoire faisait quelques centaines de Mo (!)[1].
Mais je l'ai supprimé en urgence il y a quelque temps avant de voir les erreurs à l'intérieur (pas mal d'applications dont le courier râlaient de ne plus avoir d'espace dans mon home) et pour le moment il n'est pas réapparu. Ça pourrait donc venir de là...
Faudrait que je redémarre X pour voir si la place se libère.
Footnotes: [1] Le fichier a eu le temps de grossir alors que mon uptime en est à 49 jours et que X n'a planté (shooté par le noyau pour allocation mémoire anarchique) que 2 fois. Faudrait que je prenne du temps pour voir l'appli X qui a des problèmes. Ça serait plus sain.
Sébastien Kirche
Stephane Chazelas
2004-12-02, 02:47(+01), Sebastien Kirche: [...]
Effectivement, find /proc/*/fd -lname "*deleted*" me liste quelque chose, mais ça n'est pas trop parlant pour moi.
ls -Lhs devrait donner leur taille.
Exemple:
~$ exec 3> /tmp/a ~$ rm /tmp/a ~$ seq 10000 >&3 ~$ ls -shL /tmp/a ls: /tmp/a: No such file or directory (1)~$ ls -shL /proc/$$/fd/3 48K /proc/4844/fd/3
[...]
Par contre un bête lsof | grep /home me liste entre autres un certain nombre de lignes «/.xsession-errors (deleted)». Fichier qui de mémoire faisait quelques centaines de Mo (!)[1].
Faudra redemarrer X pour que toutes les commandes qui ont ce fichier ouvert le ferment (en quittant).
-- Stephane
2004-12-02, 02:47(+01), Sebastien Kirche:
[...]
Effectivement, find /proc/*/fd -lname "*deleted*" me liste quelque chose,
mais ça n'est pas trop parlant pour moi.
ls -Lhs devrait donner leur taille.
Exemple:
~$ exec 3> /tmp/a
~$ rm /tmp/a
~$ seq 10000 >&3
~$ ls -shL /tmp/a
ls: /tmp/a: No such file or directory
(1)~$ ls -shL /proc/$$/fd/3
48K /proc/4844/fd/3
[...]
Par contre un bête lsof | grep /home me liste entre autres un certain nombre
de lignes «/.xsession-errors (deleted)». Fichier qui de mémoire faisait
quelques centaines de Mo (!)[1].
Faudra redemarrer X pour que toutes les commandes qui ont ce
fichier ouvert le ferment (en quittant).
Effectivement, find /proc/*/fd -lname "*deleted*" me liste quelque chose, mais ça n'est pas trop parlant pour moi.
ls -Lhs devrait donner leur taille.
Exemple:
~$ exec 3> /tmp/a ~$ rm /tmp/a ~$ seq 10000 >&3 ~$ ls -shL /tmp/a ls: /tmp/a: No such file or directory (1)~$ ls -shL /proc/$$/fd/3 48K /proc/4844/fd/3
[...]
Par contre un bête lsof | grep /home me liste entre autres un certain nombre de lignes «/.xsession-errors (deleted)». Fichier qui de mémoire faisait quelques centaines de Mo (!)[1].
Faudra redemarrer X pour que toutes les commandes qui ont ce fichier ouvert le ferment (en quittant).
-- Stephane
Sebastien Kirche
Le 2 déc 2004, Sebastien Kirche s'est exprimé ainsi :
Faudrait que je redémarre X pour voir si la place se libère.
Stoppé X, tué 1 ou 2 process qui n'avaient rien à faire là et les 400+ Mo qui erraient dans les limbes m'ont été rendus par le noyau :)
Le 2 déc 2004, Stephane Chazelas vraute :
2004-12-02, 02:47(+01), Sebastien Kirche: [...]
Effectivement, find /proc/*/fd -lname "*deleted*" me liste quelque chose, mais ça n'est pas trop parlant pour moi.
ls -Lhs devrait donner leur taille.
Exemple:
~$ exec 3> /tmp/a ~$ rm /tmp/a ~$ seq 10000 >&3 ~$ ls -shL /tmp/a ls: /tmp/a: No such file or directory (1)~$ ls -shL /proc/$$/fd/3 48K /proc/4844/fd/3
Zut, j'ai oublié de vérifier la taille avec ta commande ls -Lhs. Ce sera pour la prochaine fois. :/
Faudra redemarrer X pour que toutes les commandes qui ont ce fichier ouvert le ferment (en quittant).
C'est ok là.
Note pour plus tard : faire gaffe en supprimant des fichiers qui sont susceptibles d'être ouverts...
Sébastien Kirche
Le 2 déc 2004, Sebastien Kirche s'est exprimé ainsi :
Faudrait que je redémarre X pour voir si la place se libère.
Stoppé X, tué 1 ou 2 process qui n'avaient rien à faire là et les 400+ Mo
qui erraient dans les limbes m'ont été rendus par le noyau :)
Le 2 déc 2004, Stephane Chazelas vraute :
2004-12-02, 02:47(+01), Sebastien Kirche:
[...]
Effectivement, find /proc/*/fd -lname "*deleted*" me liste quelque
chose, mais ça n'est pas trop parlant pour moi.
ls -Lhs devrait donner leur taille.
Exemple:
~$ exec 3> /tmp/a
~$ rm /tmp/a
~$ seq 10000 >&3
~$ ls -shL /tmp/a
ls: /tmp/a: No such file or directory
(1)~$ ls -shL /proc/$$/fd/3
48K /proc/4844/fd/3
Zut, j'ai oublié de vérifier la taille avec ta commande ls -Lhs. Ce sera
pour la prochaine fois. :/
Faudra redemarrer X pour que toutes les commandes qui ont ce
fichier ouvert le ferment (en quittant).
C'est ok là.
Note pour plus tard : faire gaffe en supprimant des fichiers qui sont
susceptibles d'être ouverts...
