Newsgroup: it.comp.os.linux.sys
Titolo: /usr 92% full? No, solo 10% full...

Ok, questa e' stramba e se qualcuno ha qualche idea...
Ho un server con Slackware ospitato presso uno dei nostri hosting
partner, stamani il mio monitor di sistema ha cominciato a strillare
che /usr era piena al 92%. Dato che non c'e' una mazza installata
ho cominciato a preoccuparmi. Una volta collegato ho trovato un
qualcosina di strano...
Un bel df -h mostra /usr pieno al 92%, ma un du -sh /usr mi ritorna
solo un 10% di spazio usato (450 Mb su oltre 4 Gb di partizione).
Dopo un bel po' di scavezzamenti (/usr/tmp? /usr/local/src?
/usr/etc? ho pure pensato ad un qualche cracking e verificato che tutti 
i binari fossero Ok), ho optato per una soluzione 'a'la Microsoft ed 
ho dato un reboot.
Voila', adesso df mi dice solo 10% usato...
Mi viene un dubbio, ma df dove cacchio le legge le cose? Sara' un
qualche buffer che non si svuota??
Davide
-- 
| "The human brain is like an enormous fish -- it is flat and slimy and 
| has gills through which it can see."   -- Monty Python 
| 
| 

 writes:
DB> Mi viene un dubbio, ma df dove cacchio le legge le cose? Sara' un
DB> qualche buffer che non si svuota??
Se e` stato creato un  file, aperto da un'applicazione e rimosso (mentre
e` ancora  aperto), l'entry nella directory  non c'e` piu`,  ma tutte le
risorse occupate  (i-node, blocchi)  restano tali fino  a che  non viene
chiuso, e "df"  mostra questo, mentre "du" si basa  sulla lista dei file
che (non) trova nelle directory.
Caso tipico, i file di log. Al reboot l'applicazione che li tiene aperti
ovviamente si ferma  (e quindi tutti i file vengono  chiusi) e di conse-
guenza lo  spazio occupato si libera automagicamente.  Lo stesso succede
con alcune applicazioni che possono effettuare operazioni tipo:
fd = open ("path/name", O_CREAT);
unlink("path/name");
while (1)
        write (fd, ...);
(ottimo sistema per  fare un "file system full" e  non saper chi ringra-
ziare...)
Saluti,
Luca Polo.
-- 
Luca...@gest.unipd.it
 --- 
http://www.gest.unipd.it/~jake
----------------------------------------------------------
One Ping to rule them all. One Ping to find them.
One Ping to bring down them all.
And in the darkness crash them.         [The Lord of the Pings]

 Caso tipico, i file di log.
E' cio' che ho ponzato per prima cosa, ma si dia il caso che tutti i 
file di log siano su /var/log, ed il rotate mi assicura che _tutte_
le applicazioni ricevono il loro giusto "HUP" a mezzanotte.
Davide
-- 
| Let's just say that where a change was required, I adjusted.  In every
| relationship that exists, people have to seek a way to survive.  If
| you really care about the person, you do what's necessary, or that's
| the end.  For the first time, I found that I really could change, and 

> Caso tipico, i file di log.
DB> E' cio' che ho ponzato per prima cosa, ma si dia il caso che tutti i 
DB> file di log siano su /var/log, ed il rotate mi assicura che _tutte_
DB> le applicazioni ricevono il loro giusto "HUP" a mezzanotte.
Non sempre HUP funziona come dovrebbe... e non e` detto che comunque ob-
blighi l'applicazione a chiudere e riaprire i file che usa.
Il problema  e` che se  una roba del  genere ti capita "una  tantum" non
c'e` praticamente modo di capire  esatamente cosa e` successo. Se capita
piu`  volte, allora magari  con "lsof"  e allegri  compagni si  riesce a
trovare il colpevole (che non e` mai il maggiordomo: avete mai letto sul
giornale "maggiordomo colpevole di  omicidio" ? BTW, mi piacerebbe tanto
sapere da dove viene fuori la storia del maggiordomo...).


 hummm... e come potrebbe essere stato rimosso un file ancora aperto?
a me pare che se uno apre un file ottenendo un file descriptor, poi fa
l'unlink di quel file, senza fare la close sul fd, il file non appare
con ls, ma chi aveva aperto il file prima dell'unlink puo' continuare
ad utilizzarlo, e verra' rimosso solo quando non c'e' piu' nessun
processo che ha riferimenti a quel file.

 c'e` praticamente modo di capire  esatamente cosa e` successo.
...e' quello che temevo...
Davide
-- 
| "Being disintegrated makes me ve-ry an-gry!" <huff, huff> 
| 
| 
| 

 Voila', adesso df mi dice solo 10% usato...
non so dari una risposta, ma posso confermarti che quando cancello molta
roba (ad esempio vecchie news) sin quando non riavvio df non si accorge
dello spazio liberato. Magari una volta che avviene il mount della
partizione scrive da qualche parte lo spazio occupato (o libero) di
quella partizione...
-- 
| Ciao Cacciavite       Linux Registered User #297089
| Powered by *Debian GNU/Linux 3.0* on Celeron 667MHz 	  

 
man lsof
in base alla dimensione trovi il PID del processo che lo tiene aperto.
in /proc vai a vedere tutto quello che riguarda il processo
... a meno che abbiano compromesso il server con un rootkit :-((
Claudio
-- 
Claudio P. - happy Linux user -

 ho dato un reboot.
hai provato un semplice "sync" prima di optare per il reboot?
--
Massimiliano.

 hai provato un semplice "sync" prima di optare per il reboot?
No, ci ho pensato dopo, purtroppo.
Davide
-- 
| Know thyself.  If you need help, call the C.I.A. 
| 
| 
| 

sapere da dove viene fuori la storia del maggiordomo...).
Agata Christie?

> maggiordomo...).
e> Agata Christie?
No, o  lo ricorderei (credo di  aver letto pressoche' tutti  i gialli di
Agatha Christie...).
"Googlando" un po'  ho trovato da cosa deriva il  detto: "The butler did
it" e` il  titolo di una commedia "gialla" di Tim  Kelly, seguita poi da
"The butler did it, again!".
