Newsgroup: it.comp.os.linux.sys
Titolo: spazio disco "scomparso"

ciao, ho questo problema su un centos6: delle applicazioni (che non 
conosco perche' non installate da me) sembrano riempire il disco molto 
velocemente. il problema e' che non si riesce bene a capire cosa sia 
che lo occupa perche' facendo dei 'du' sulle dir principali sembra che 
la somma delle occupazioni non sia pari a quanto detto da 'df'.
 
/ e' su ext4 e il disco e' "fatto" con LVM che raggruppa piu' di un 
disco fisico, in quanto per tamponare i primi riempimenti si e' 
aggiunto degli altri hard disk per aumentare la capacita' totale (la 
macchina e' virtuale).
 
Una cosa simile mi era capitata anche su una macchina fisica ma non 
ricordo come risolsi o quale fosse la causa.
Purtroppo la macchina e' stata amministrata "cosi' cosi'": hanno 
installato applicazioni che scrivono grossi log senza ruotarli e per 
giunta in /root cosi' saturano anche la riserva di root.
 
grazie in anticipo per ogni aiuto....
 
-- 
Tinto
 
 

la somma delle occupazioni non sia pari a quanto detto da 'df'.
 
Prova a dare il comando:
 
lsof | grep deleted
 
e vedi se c'e' qualche processo che ha dei file temporanei enormi.
 
Nel caso, basta che tu faccia un restart di quel processo. Occhio a
farlo ordinatamente tenendo conto delle dipendenze fra processi.
 
===========
 
Per esempio ti trovi a leggere:
 
sqlwatch     5331       lambda    3w      REG              104,4
13433044979
   13058575 /var/log/log-gestionale.log (deleted)
 
e a quel punto chiedi con aria innocente "Hey, ma questo gestionale
fa dei log IMMENSI! Com'e', che non hanno saturato la macchina mesi
fa?"
 
Salta su un collega giulivo e dice "Ho rimosso io i log vecchi!".
 
E tu: "Ma non hai mica riavviato il gestionale, eh?"
 
"No, certo che no!"
 
E tu ti volti, estrai e spari. Nessun giudice ti condannerà (cit.)
 
Leonardo "Questo è Harold Francis Callahan... il nuovo sistemista"
 
-- 
Surstangas via akcipitr', la cxeval' fojnumas nur:
Jen vigla damo en brakum', kaj vi pensas pri forkur'?
Do li turnis sin, kaj turnis sin, kaj ekdormis sen singard';
Kaj lin apudis je l' vekigx, soldatoj kaj Barnard'.

 Leonardo "Questo è Harold Francis Callahan... il nuovo sistemista"
 
ahahah grandissimo! :)
in realta' prima di leggere il tuo messaggio ho fatto un reboot e 
infatti lo spazio e' ricomparso. l'avevo suggerito ai tizi ma non 
l'hanno fatto, non si sa perche'. beh forse si': a giudicare dalle 
domande che mi hanno fatto nei giorni scorsi forse non conoscevano la 
sintassi esatta del comando "reboot" ;)
 
di sicuro non devono aver mai guardato dentro alla dir logrotate se no 
gli sarebbe venuto il dubbio sul perche' dopo la rotazione c'e' un 
riavvio del demone... :D
 
grazie ancora.
 
-- 
Tinto
 
 

 riavvio del demone... :D
 
C'è un metodo alternativo (e definitivo) per sanare situazioni del
genere: usa l'opzione copytuncate in logrotate per quei log. In questo
modo non serve il riavvio del gestionale (a patto di fare una
rotazione abbastanza frequente e spazio permettendo).
 

genere: usa l'opzione copytuncate in logrotate per quei log.
 
Eheheh. Tu pensi d'aver trovato qualcosa a prova di stupido, ma la Natura
prontamente crea degli stupidi peggiori.
 
Alternativo si', ma definitivo... non sempre. Solo se ti va liscia :-)
 
Il copytruncate effettua una chiamata di truncate() sul logfile e benche'
sulla man page di truncate(2) non ci sia scritto, questo non ha il minimo
effetto sui fd gia' aperti (be', dipende dall'IOSS).
 
Se il fd e' aperto in O_APPEND, la chiamata successiva legge l'end-extent
dall'inode, e un file troncato a zero e "appenduto" :-) di 1 K diventa un
file reale di 1024 byte snocciolati uno dietro l'altro.
 
I programmatori fiduciosi in genere usano O_APPEND, pensando che ci sara'
un sistemista che pulisce dove loro sporcano. Non e' gentile, ma, almeno,
ognuno a lo so paisi fa il mestiere so'.
 
E il risultato e' che logtruncate funziona (rimane esposto un pezzetto di
log, ma poca roba) e tutti sono contenti.
 
Pero' c'e' il rischio che tu trovi il programmatore fubbo, che pensa "Ma,
se nessuno mi cancella il log ed io appendo, riempio ugniòsa! E mi prendo
la colpa me!" -- e allora risolve: "Apro in O_WRITE, cosi' se il log c'e'
gia' lo sovrascrivo".
 
Intuitivamente, codesto programmatore pensa anche che il daemon ogni poco
verra' riavviato.
 
In queste condizioni il fd si ricorda a che punto stava e fa buffering, e
la scrittura seguente non solo al 90% scrivera' un pezzo di log parziale,
ma lo fara' DA UN CERTO OFFSET.
 
Cosi' si crea un file sparso, che occupa sempre 1K (o piu' probabilmente,
in media, 3K -- da 1K a 1K+4K, essendo 4K il paging buffer del fd). Pero'
su disco risulta lungo come prima piu' un K.
 
Non e' un grandissimo problema tranne che:
 
	a) Nei backup shtùpidi e completamente non compressi,
	   il sistema lo tratta come file normale e quindi ti
	   sbatte sul nastro mezzo gigabyte di zeri. Avendoci
	   compressione, diventano 5 MB di zeri compressi che
	   e' pur sempre qualcosa, piu' 1 K di log reali. Sui
	   sistemi furbi rimane 1 K di sparse, ma sono pochi.
 
	b) Tutte o quasi le utilità statistiche strillano che
	   in quella dir c'e' un monte di dati - escono dalle
	   fottute pareti! - e fanno passare "sotto silenzio"
	   altre dir con magari PIU' dati reali inutili.
 
Sicche' il mio suggerimento e',
 
	* HUP al daemon se lo prevede (quelli bravi lo fanno tutti), non
	  hai downtime ne' perdita di dati, non rischi niente.
 
	* altrimenti riavvio del daemon se possibile. Piccolo downtime e
	  nessuna perdita di dati, zero rischi.
 
	* copytruncate. Zero downtime, bassissimi rischi di perdere log,
	  ma CONTROLLARE COSA SUCCEDE AL FILE DI LOG e prendere adeguate
	  contromisure, se possibile, in sede di backup/check.
 
	* indagare log alternativi. Vari programmi consentono di loggare
	  su pipe, socket, o syslog. Purtroppo, in genere e' perche' chi
	  li ha scritti sapeva cosa faceva, e quindi con questi medesimi
	  programmi si puo' usare proficuamente HUP.
 
Leonardo


 prontamente crea degli stupidi peggiori.
 
tipo "windows fa schifo perche' per cancellare i log devo stoppare il 
programma, che bello linux che posso cancellarlo e non si lamenta.... 
un momento: come mai il mio disco e' pieno???? ah e' una macchina 
virtuale... sara' sicuramente colpa dell'hypervisor" :D
 
Scherzi a parte, grazie molto per le spiegazioni. Purtroppo non mi e' 
venuto in mente al volo cosa potesse essere perche' non mi verrebbe mai 
in mente di cancellare un file mentre un demone lo sta usando... e 
quando ho configurato qualche rotazione di log prima ho guardato come 
erano fatte quelle... fatte bene :)
 
Provero' a spiegare ai tizi 'ste cose (manco fosse compito mio... 
vabbe'), tentando anche di introdurgli il concetto "esiste un 5% di 
spazio riservato a root per evitare di trovarsi una macchina dove non 
puoi neanche piu' fare 'vi /etc/fstab', ma se installi roba che scrive 
cache, logs e chissa' che altro sotto /root... :D
 
Buona domenica, o quel che ne resta :)
 
-- 
Tinto
 
 

cache, logs e chissa' che altro sotto /root... :D
 
Si', occhio, lo spazio è riservato all'UTENTE root... puo' essere anche
altrove, come in /var/log.


 altrove, come in /var/log.
 
giusto, sono stato impreciso; comunque hanno installato tutto sotto 
/root, ogni cosa viene salvata, generata, elaborata, scritta li', tutto 
come root.
Perche'? Azzardo: "perche' cosi' sei sicuro che funziona!" :D
 
-- 
Tinto
 
 

Perche'? Azzardo: "perche' cosi' sei sicuro che funziona!" :D
 
"Si', questa e' la seconda cosa al mondo che di sicuro funziona"
annui' l'ispettore Callaghan estraendo la prima.
 
(titoli di coda)
 
Leonardo e il sysadmin porn


 Leonardo e il sysadmin porn
 
:-)
 
-- 
Tinto