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.
sudo du -sh /var/* ~/.xsession-errors? (te dwa miejsca, których spodziewałbym się wysadzić, jeśli coś jest głupie). W przeciwnym razie jestem z Eliasem - to wskazuje na problemy z dyskiem. Weź to na poważnie.