Jak zatrzymać tę ciągłą utratę wolnego miejsca?

Uruchomiłem Ubuntu, jak zwykle, gdy nagle pojawiło się okno dialogowe z informacją, że zostało mi tylko 1,2 GB wolnego miejsca. Godzinę wcześniej miałem 30 GB wolnego miejsca.

Usunąłem niektóre rzeczy i zwiększyłem wolne miejsce do 25 GB. Ale nadal maleje. Próbowałem usunąć stare pliki dziennika i je obciąć i tak dalej, i nadal spada!

Próbowałem za pomocą narzędzia Disk Analyzer, aby dowiedzieć się, skąd wzięła się ta cała utrata wolnego miejsca, ale to nie zadziałało, ponieważ pokazało wszystko tak, jak powinno być. Uruchomiłem ponownie i ostatecznie Ubuntu przeprowadził kontrolę dysku, która w jakiś sposób zwiększyła ilość wolnego miejsca do 40 GB, ale nadal zmniejsza się o około 10 GB dziennie. Nadal próbuję znaleźć nowe sposoby na zwolnienie miejsca, ale to jest jak zautomatyzowany proces zmniejszania miejsca na dysku, którego nie mogę zatrzymać.

Nie wiem co mam robić. Jak znaleźć przyczynę i zatrzymać zmniejszanie się wolnego miejsca?

Oto dane wyjściowe z 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

Masz jakieś dzienniki poza kontrolą. Zamiast usuwać jak szalone codziennie, znajdź szybko rosnący plik lub pliki i zajrzyj do środka, aby sprawdzić, co może być przyczyną tego. Być może jakiś program wiruje w pętli rejestrując jakiś warunek. Wyłącz ten program, wyłącz jego rejestrowanie lub spróbuj naprawić warunek, na który narzeka.

Jeśli plik rośnie na twoich oczach i nie masz pojęcia, który program do niego pisze, możesz łatwo go znaleźć. Oto przykład. Kto ma /var/log/syslogotwarty? Używamy fuserpolecenia:

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

/var/log/syslogOtwarty jest tylko jeden proces . To jest proces 602. Co to jest? Nie zawracajmy sobie głowy psi grep, ale spójrzmy /procbezpośrednio na system plików:

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

Aha, tak jest rsyslogd. Nie dziwi nas to, że rsyslogdsię /var/log/syslog/otworzyło.

Ta metoda nie gwarantuje, że zadziała. Powodem jest to, że programy nie muszą mieć otwartych plików, aby do nich pisać. Załóżmy, że masz proces, który otwiera plik, dołącza do niego, a następnie zamyka. Będziesz miał nieco trudniejsze dochodzenie. Możesz biegać fuserwiele razy, aż przypadkiem złapiesz proces „na gorącym uczynku”. Ten sam proces może szybko powstać i zniknąć. Innym problemem jest to, że wiele procesów może mieć otwarty plik, ale tylko jeden go powiększa. W takim przypadku możesz prześledzić ich wywołania systemowe.

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

Ups! Otwarte są dwa procesy: 1234 i 23459. Zobaczmy, co robią:

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

Nic nie robi, po prostu blokuje selectpołączenie. Ctrl-C, aby przerwać śledzenie:

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

Sprawdź następny:

# 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

Ups, ten ciągle pisze. To musi być zły. Możemy nawet sprawdzić, czy deskryptor pliku 5, do którego pisze proces, jest w rzeczywistości dużym plikiem:

# 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

Nie podejrzewam, że masz uszkodzony system plików, ale aby wymusić pełne sprawdzenie, nie musisz uruchamiać dysku DVD.

Po pierwsze, sprawdź maksymalną liczbę podłączeń twojego systemu plików. Zidentyfikuj partycję za pomocą polecenia df. Przykład na systemie Ubuntu, który mam tutaj:

# 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

Widać, że /system plików jest zamontowany /dev/sda1. Podobnie /dev/sda1jak urządzenie pamięci masowej partycji głównej (i jedynej partycji w tym konkretnym systemie).

Spójrzmy na niektóre atrybuty tego systemu plików. Jest to bezpieczne, nawet jeśli jest zamontowane. Polecenie generuje dużo danych wyjściowych. Oto fragment:

$ 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 ... ]

Hej, liczba montaży jest równa maksymalnej liczbie montowań. Następnym razem, gdy uruchomię ponownie, nastąpi sprawdzenie systemu plików. Ważne jest to, że liczba montowań jest wartością dodatnią. Jeśli twoje wynosi zero, zmień go na pewną wartość dodatnią, np. 22 używając tune2fs -c 22 /dev/whatever. Zero oznacza, że ​​sprawdzanie nigdy nie jest wymuszane, niezależnie od tego, ile razy partycja jest zamontowana. Rzadko uruchamiane ponownie systemy powinny mieć tutaj niskie wartości. Serwer, który jest wyłączany raz w roku, prawdopodobnie mógłby użyć fsck przy każdym ponownym uruchomieniu. Możesz również ustawić interwały sprawdzania oparte na dacie.

Teraz, aby wymusić sprawdzenie, możesz przesłonić rzeczywistą liczbę, aby była większa lub równa maksimum, a następnie uruchomić ponownie. Że jest zrobione z kapitału C: tune2fs -C 1234 /dev/whatever. Teraz partycja wygląda tak, jakby została zamontowana 1234 razy bez sprawdzenia, co jest większe niż jedno- lub dwucyfrowe maksimum.

Kontrola dysku zwolniła część miejsca, co sugeruje, że ten problem (lub jego część) może być spowodowany uszkodzeniem systemu plików. W takim przypadku powinieneś być w stanie zwolnić więcej miejsca poprzez skanowanie i naprawę systemu plików. Jeśli jednak uszkodzenie trwa wiecznie (co może się zdarzyć lub nie), zwykle oznacza to, że dysk twardy umiera. Jeśli kopie zapasowe (dokumentów i innych ważnych plików, które trudno byłoby zastąpić) nie są całkowicie aktualne, wykonaj kopię zapasową wszystkich ważnych teraz!

Aby sprawdzić i naprawić dysk, nie można go zamontować (przynajmniej nie do odczytu i zapisu). Więc powinieneś uruchomić narzędzie do naprawy ze środowiska na żywo (live CD / DVD lub USB). Najpierw musisz znaleźć nazwę urządzenia na partycji zawierającej twoje pliki.

Dlatego w zainstalowanym systemie uruchom:

mount | grep ' on / '

(Pamiętaj o wpisaniu spacji między /i '.)

Dostaniesz coś takiego:

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

Tekst przed - onw przykładzie z mojego komputera /dev/sda8- jest pełną nazwą urządzenia dla partycji root ( /). Zapisz to - będzie ci potrzebne.

Następnie uruchom komputer z komputera stacjonarnego CD / DVD lub dysku flash USB Ubuntu, podobnie jak w przypadku oryginalnej instalacji Ubuntu. (Jeśli jest to system Wubi, zainstalowany z instalatorem Windows, daj nam znać. Nie spodziewam się tego, biorąc pod uwagę to, co zgłosiłeś, ale w takim przypadku procedura będzie inna).

Wybierz Wypróbuj Ubuntu bez instalacji (nie Instaluj Ubuntu ). Gdy pojawi się działający pulpit, naciśnij Ctrl+ Alt+, Taby otworzyć okno terminalu. Następnie uruchom to polecenie:

sudo e2fsck -fkccp /dev/sda8

Pamiętaj jednak, aby zastąpić /dev/sda8ją prawidłową pełną nazwą urządzenia dla swojej /partycji, tak jak to opisano powyżej.

To może zająć chwilę. Te czawarte w tej komendzie, bo to skanowanie powierzchni dysku w poszukiwaniu błędów, a także system plików (oraz oznaczyć żadnych złych obszary jako zła, więc nie są one używane) Opcje. Możesz pominąć cc, jeśli chcesz (jeśli chcesz, możesz też pominąć k), ale zalecamy trzymanie ich w środku.

Możesz zostać poproszony o naprawienie niektórych problemów, jeśli e2fsckuważasz , że istnieje duże prawdopodobieństwo, że próba ich rozwiązania może spowodować utratę danych. (To psprawia, że ​​rozwiąże wszelkie problemy, które jest pewien, że można je naprawić bez powodowania komplikacji).

Zalecam, abyś był bardzo skłonny pozwolić mu naprawić wszystko, czego chce, ponieważ powinieneś to robić dopiero po upewnieniu się, że kopie zapasowe są aktualne . Jeśli chcesz, aby próbować nawet potencjalnie niebezpieczne poprawki bez monitowania, wymienić psię y.

Następnie uruchom ponownie system Ubuntu i sprawdź, czy jest wolne miejsce. Jeśli tak nie jest lub problem występuje nadal, prosimy o komentarz i edycję pytania, aby podać szczegółowe informacje.

ten problem został rozwiązany, to zapora zapisuje mnóstwo dzienników i plików kodujących tvmobili