Come posso fermare questa costante perdita di spazio libero?


15

Stavo eseguendo Ubuntu, come al solito, quando improvvisamente ho avuto una finestra di dialogo che diceva che mi rimanevano solo 1,2 GB di spazio libero. Un'ora prima, avevo 30 GB di spazio libero.

Ho eliminato alcune cose e portato lo spazio libero fino a 25 GB. Ma continua a diminuire. Ho provato a rimuovere i vecchi file di registro e troncare i file di registro e così via, e continua a diminuire!

Ho provato a utilizzare Disk Analyzer per scoprire da dove provenisse tutta questa perdita di spazio libero e che non ha funzionato, poiché ha mostrato tutto come dovrebbe essere. Ho riavviato e alla fine Ubuntu ha fatto un controllo del disco che in qualche modo ha riportato lo spazio libero a 40 GB, ma continua a diminuire di circa 10 GB al giorno. Continuo a cercare nuovi modi per liberare spazio, ma è come un processo automatizzato di riduzione dello spazio su disco che non riesco a fermare.

Io non so cosa fare. Come posso trovare la causa e impedire che il mio spazio libero diminuisca?

Ecco l'output di sudo du -sh /var/* ~/.xsession-errors:

13M /var/backups
204M    /var/cache
112M    /var/crash
4.0K    /var/games
503M    /var/lib
4.0K    /var/local
0       /var/lock
9.5G    /var/log
85M     /var/mail
4.0K    /var/metrics
24K     /var/opt
0       /var/run
1.7M    /var/spool
391M    /var/tmp
11G     /var/tvmobili
20K     /var/www
224K    /home/school/.xsession-errors

2
Puoi modificare il post per aggiungere l'output di per sudo du -sh /var/* ~/.xsession-errorsfavore? (quei due posti che mi aspetterei di esplodere se c'è qualcosa di sciocco). Altrimenti, sono con Eliah - questo è indicativo di problemi con il disco. Prendi questo sul serio.
Oli

Risposte:


26

Hai dei registri fuori controllo. Invece di eliminare come un matto ogni giorno, trova il file oi file in rapida crescita e guarda dentro per scoprire cosa potrebbe causare questo. Forse un programma gira in loop registrando una condizione. Disabilita quel programma, disabilita la sua registrazione o prova a correggere la condizione di cui si lamenta.

Se un file cresce davanti ai tuoi occhi e non hai idea di quale programma vi stia scrivendo, potresti scoprirlo facilmente. Ecco un esempio Chi ha /var/log/syslogaperto? Usiamo il fusercomando:

# fuser /var/log/syslog
/var/log/syslog:      602

È /var/log/syslogaperto solo un processo . È il processo 602. Cos'è quello? Non preoccupiamoci di pse grep, ma guardiamo /procdirettamente al filesystem:

# ls -l /proc/602/exe
lrwxrwxrwx 1 root root 0 Mar 29 17:45 /proc/602/exe -> /usr/sbin/rsyslogd

Ah, lo è rsyslogd. Non siamo sorpresi che si rsyslogdsia /var/log/syslog/aperto.

Questo metodo non è garantito per funzionare. Il motivo è che i programmi non devono tenere aperti i file per poter scrivere su di essi. Supponiamo di avere un processo che apre un file, lo accoda e poi lo chiude. Avrai un'indagine un po 'più difficile. Potresti correre fusermolte volte fino a quando per caso non prendi il processo "in flagrante". Questo stesso processo potrebbe entrare e uscire rapidamente dall'esistenza. Un altro problema è che più processi potrebbero avere il file aperto, ma solo uno lo sta ingrandendo. In tal caso, è possibile tracciare le loro chiamate di sistema.

# fuser /var/log/huge-annoying-file
/var/log/huge-annoying-file:   1234 23459

Oops! Sono aperti due processi: 1234 e 23459. Vediamo cosa stanno facendo:

# strace -p 1234
Process 1234 attached - interrupt to quit
select(1, NULL, NULL, NULL, {9, 922666}

Non sta facendo nulla, sta solo bloccando una selectchiamata. Ctrl-C per interrompere la traccia:

select(1, NULL, NULL, NULL, {9, 922666}^C <unfinished ...>

Controlla il prossimo:

# strace -p 23459
write(5, "Useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
^C

Oops, quello sta scrivendo costantemente. Deve essere quello cattivo. Possiamo persino verificare che il descrittore di file 5 su cui sta scrivendo il processo sia in realtà il file di grandi dimensioni:

# ls -l /proc/23459/fd/5
lr-x------ 1 root root 64 Apr  3 23:39 /proc/23459/fd/5 -> /var/log/huge-annoying-file

Non sospetto che tu abbia un filesystem corrotto, ma per forzare un controllo completo, non devi avviare un DVD.

Innanzitutto, rivedi l'impostazione del numero massimo di montaggi del tuo filesystem. Identifica la tua partizione usando il comando df. Esempio su un sistema Ubuntu che ho qui:

# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda1       18062108 5499320  11645284  33% /
udev              392152       4    392148   1% /dev
tmpfs             159768     768    159000   1% /run
none                5120       0      5120   0% /run/lock
none              399416     200    399216   1% /run/shm
/dev/sr0           43668   43668         0 100% /media/VBOXADDITIONS_4.1.4_74291

Puoi vedere che il /filesystem è montato /dev/sda1. Lo stesso /dev/sda1vale per il dispositivo di archiviazione della partizione root (e l'unica partizione in questo particolare sistema).

Diamo un'occhiata ad alcuni attributi di quel file system. Questo è sicuro da fare anche se è montato. Il comando emette molto output. Ecco un estratto:

$ dumpe2fs /dev/sda1
dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name:   <none>
Last mounted on:          /
[ ... SNIP ... ]
Last mount time:          Fri Mar 29 17:45:18 2013
Last write time:          Tue Mar  5 09:08:03 2013
Mount count:              22
Maximum mount count:      22
[ ... SNIP ... ]

Ehi guarda, il conteggio delle montature è uguale al conteggio delle montature massimo. La prossima volta che riavvio, ci sarà un controllo del filesystem. L'importante è che il numero di mount sia un valore positivo. Se il tuo è zero, modificalo in un valore positivo come 22 usando tune2fs -c 22 /dev/whatever. Zero significa che un controllo non viene mai forzato indipendentemente da quante volte è montata la partizione. I sistemi raramente riavviati dovrebbero avere valori bassi qui. Un server che si arresta una volta all'anno potrebbe probabilmente usare un fsck ogni volta che si riavvia. È inoltre possibile impostare intervalli di controllo basati sulla data.

Ora per forzare un controllo, puoi sovrascrivere il conteggio effettivo in modo che sia maggiore o uguale al massimo, quindi riavviare. Questo è fatto con il capitale C: tune2fs -C 1234 /dev/whatever. Ora la partizione sembra essere stata montata 1234 volte senza un controllo, che è maggiore del massimo di una o due cifre.


molto istruttivo ma il problema è stato risolto, è stato il firewall a scrivere enormi file di registro
askcompu

2
Vedi, come sospettavo. Nessuna misteriosa corruzione del disco che frustra lo spazio su e giù. Voglio dire che potrebbe spiegare un incidente isolato, ma una volta riparato, dovrebbe essere riparato. E l'unità non funziona, ci si aspetterebbe qualche errore nel log del kernel e nel panico.
Kaz

sì, ho pensato che non fosse l'unità, i test SMART dicono che è una vecchia unità ma ancora utilizzabile e funzionante
askcompu

Un modo più semplice per salvare tutti i filesystem è eseguire 'sudo touch / forcefsck; sudo / sbin / shutdown -r now '.
Blair Zajac il

3

Un controllo del disco ha liberato parte dello spazio, suggerendo che questo problema (o parte di esso) potrebbe essere dovuto alla corruzione del filesystem. In tal caso, dovresti essere in grado di liberare più spazio eseguendo la scansione e la riparazione del filesystem. Tuttavia, se la corruzione si verifica perpetuamente (il che potrebbe o non potrebbe essere il caso), di solito significa che il disco rigido sta morendo. Se i tuoi backup (dei tuoi documenti e di altri file importanti che sarebbero difficili da sostituire) non sono completamente aggiornati, esegui il backup di tutto ciò che è importante ora!

Per controllare e riparare il disco, non può essere montato (almeno non in lettura-scrittura). Quindi è necessario eseguire l'utilità di riparazione da un ambiente live (live CD / DVD o USB). Innanzitutto, dovrai scoprire il nome del dispositivo della partizione che contiene i tuoi file.

Pertanto, nel sistema installato , eseguire:

mount | grep ' on / '

(Assicurati di includere lo spazio tra il /e '.)

Otterrai qualcosa del tipo:

/dev/sda8 on / type ext4 (rw,errors=remount-ro)

Il testo prima on- nell'esempio della mia macchina - /dev/sda8è il nome completo del dispositivo per la partizione di root ( /). Scrivi questo: ne avrai bisogno.

Quindi avviare il computer da un CD / DVD desktop di Ubuntu o un'unità flash USB, come quello usato per installare Ubuntu in origine. (Se si tratta di un sistema Wubi, installato con il programma di installazione di Windows, fatecelo sapere. Non me lo aspetto, dato quello che hai segnalato, ma in tal caso, la procedura sarà diversa.)

Seleziona Prova Ubuntu senza installare (non Installa Ubuntu ). Quando si ottiene un desktop funzionante, premere Ctrl+ Alt+ Tper aprire una finestra Terminale. Quindi eseguire questo comando:

sudo e2fsck -fkccp /dev/sda8

Assicurati di sostituire /dev/sda8con il nome completo del dispositivo corretto per la tua /partizione, come hai ottenuto attraverso il metodo descritto sopra.

Questo potrebbe richiedere del tempo. Le copzioni incluse in quel comando fanno sì che esegua la scansione della superficie del disco alla ricerca di errori e del filesystem (e contrassegni le aree danneggiate come non valide, in modo che non vengano utilizzate). Puoi lasciare ccfuori se vuoi (se lo fai, puoi anche lasciare fuori k), ma ti consiglio di tenerli dentro.

È possibile che venga richiesto di risolvere alcuni problemi, se si e2fsckritiene che vi sia una probabilità significativa che il tentativo di risolverli possa causare la perdita di dati. (Lo pfa in modo che risolverà tutti i problemi che è sicuro di poter risolvere senza causare complicazioni.)

Vi consiglio di essere fortemente inclinato per permettere di risolvere ciò che vuole, dal momento che si dovrebbe fare solo questo dopo assicurandosi che i backup sono in corso , in ogni caso. Se si desidera tentare anche correzioni potenzialmente pericolose senza richiedere conferma, sostituire pcon y.

Successivamente, riavvia il sistema Ubuntu e verifica se lo spazio è libero. In caso contrario, o se il problema persiste, si prega di commentare e modificare la domanda per fornire dettagli.


cosa succede se non ho nulla per il backup?
askcompu

1
@ user2045360 Rubare, saccheggiare, prendere in prestito o acquistare alcuni. O spingilo online (Ubuntu One, Dropbox, Google Docs, S3, ecc.).
Oli

@ user2045360 Dipende da quanti e che tipo di file importanti hai. Se sono costituiti da 20 documenti di ufficio (o anche 100, se sei paziente), puoi inviarli via email a te stesso. Puoi anche utilizzare i servizi di archiviazione cloud, come Ubuntu One o DropBox (fai solo attenzione: se imposti qualcosa per la sincronizzazione e un file viene eliminato o modificato sul tuo computer, la stessa modifica avverrà nel cloud). D'altra parte, se sei un regista e hai 300 gigabyte di filmati, probabilmente l'unica opzione è quella di acquistare (o, come suggerisce Oli, prendere in prestito) alcuni supporti di archiviazione, come un disco rigido esterno.
Eliah Kagan,

non ho soldi e nessuno da cui prendere in prestito, quante possibilità c'è la perdita di dati con questo comando?
askcompu

@ user2045360 La probabilità di perdita di dati da quel e2fsckcomandod è piuttosto bassa, specialmente se non si preme yper qualcosa che ti avverte che potresti perdere dati. Ma eseguire questo comando non è il motivo per cui è necessario eseguire il backup dei dati. È necessario eseguire il backup dei dati perché la natura rapida e continua della tua caduta nello spazio libero suggerisce fortemente che il tuo disco rigido potrebbe essere completamente guasto fisicamente . Se ciò accade, perderai tutti i dati su di esso e quasi sicuramente non sarai in grado di recuperarli. Altri modi per eseguire il backup includono in rete su un altro computer o su CD / DVD.
Eliah Kagan,

0

questo problema è stato risolto, era il firewall a scrivere tonnellate di log e file di codifica tvmobili

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.