Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Mam pewien problem.
Maszyna wirtualna (Debian 7) gdy chcę coś zrobić w /var/log system potwornie zamula. Zjada cały ram i wchodzi na swap.
Nawet przy zwykłym listowaniu plików (ls -lah /var/log).
Nie wiem co tam jest narobione bo nie mogę nawet podejrzeć struktury katalogu (nazwy plików i zajmowane miejsce).
Jak z crona odpalany jest logrotate to jest to samo.
Sprawdziłem już 5 razy dysk przy rebocie (zanim partycja zostanie zamontowana) fsck nie zgłasza żadnych błędów.
Z tego co zauważyłem problem dotyczy tylko /var/log po reszcie dysku mogę bez problemu "chodzić".
Wyłączyłem wszystkie usługi/demony jakie są i nadal to samo.
Pisałem do supportu czy na hoście na którym stoi ta virtualka jest wszystko OK ale póki co nie mam odpowiedzi.
Czy ktoś miał coś podobnego? Co z tym robić? Bo nie mogę tak zostawić systemu.
Offline
Logrotate też muli? czy może zapomniałeś go zainstalować i skonfigurować?
W razie czego, do ratowania doopy przy podobnych symptomach, od niego zaczynam:
#!/bin/bash find /var/log/* -type f -mtime +3 | egrep -vi 'history.log|term.log'| xargs rm -f; apt-get autoclean & rm -Rf /root/.local/share/Trash/* rm -Rf /.Trash-*/* rm -Rf /home/.Trash-*/* rm -Rf /media/box/.Trash-*/*
Chociaż u Ciebie podejrzewałbym, ze jakiś program zapisał sobie w logu kilka GB, i teraz są z tym jaja.
Ostatnio edytowany przez Jacekalex (2015-06-14 11:45:30)
Offline
logrotate też zamula (wszystko co jest odpalane w /var/log)
System miał uptime ponad rok i wszystko chodziło OK, teraz w piątek zauważyłem duży load i pociągnięcie na SWAP dlatego zacząłem dociekać co jest grane.
co do zajętości:
#ls -ldh /var/log drwxr-xr-x 15 root root 94M Jun 14 10:44 /var/log
Jakiekolwiek listowanie zawartości zamula nie daje odpowiedzi i proces wisi, muszę go ubić ręcznie żeby spadł load.
Ostatnio edytowany przez life (2015-06-14 11:49:54)
Offline
1996
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:19:06)
Offline
Wszystko jest na jednej partycji ext4 (dlatego fsck musiałem dać przy rebocie bo zamontowanej nie sprawdzę poprawnie).
Ale jak wspomniałęm fsck nic niepokojącego nie wywala
cat /var/log/fsck/checkroot Log of fsck -C -f -y -t ext4 /dev/vda1 Sun Jun 14 10:43:50 2015 fsck from util-linux 2.20.1 e2fsck 1.42.5 (29-Jul-2012) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/vda1: 1155884/2559088 files (0.1% non-contiguous), 5313566/10229248 blocks Sun Jun 14 10:44:27 2015 ----------------
A jeszcze jedna ciekawostka.
Odczytywać i zapis do plików w /var/log mogę robić (jak widać powyżej), nie wiem czy do wszystkich bo trochę tam tego jest a wy listować nie jestem w stanie.
System to serwer standardowo usługi (www mail mysql itp.)
Ostatnio edytowany przez life (2015-06-14 11:54:48)
Offline
po prostu logrotate nie kasuje starych plików (tak podejrzewałem, a jak zobaczyłem 94M to już mam pewność).
niestety masz problem. ja bym skasował wszystkie pliki w /var/log za pomocą finda i dopiero potem bawił się w naprawianie. coś w stylu
find /var/log -type f -delete
czy jakoś tak (sprawdź w manualu). oczywiście zapuściłbym to w piątek po południu.
następnie przemianowałbym /var/log na /var/dupa, założył nowy katalog /var/log i skopiował wsio ze starego (struktura katalogów i prawa). w międzyczasie można sobie poczytać o konfigurowaniu logrotate...
Offline
A może coś wisi (jako zombie) i blokuje /var/log?
Zobacz może:
lsof / | grep '/var/log/'
Może tam coś dziwnego zauważysz.
@ethanak
Raczej tak:
find /var/log/* -type f -mtime +3 | egrep -vi 'history.log|term.log'| xargs rm -f;
https://forum.dug.net.pl/viewtopic.php?pid=288090#p288090
Ostatnio edytowany przez Jacekalex (2015-06-14 12:05:15)
Offline
e tam - to można przez regexpa i -and -not zrobić :) szybsze będzie... tak mi się wydaje.
Offline
ethanak napisał(-a):
po prostu logrotate nie kasuje starych plików (tak podejrzewałem, a jak zobaczyłem 94M to już mam pewność).
94MB to nic wielkiego sam plik mail.log po dniu pracy ma około 30MB a do tego dochodzą skompresowane logi (trzymam je 30 dni).
Jak wspomniałem to serwer na którym jest koło 200 kont pocztowych do tego www i kilka innych usług a lubię mieć w logach nieco więcej informacji niż tylko warn i err.
Tak więc sama wielkość zajmowanego miejsca przez ten katalog mnie nie zatrważa.
lsof / | grep '/var/log'
Nic niepokojącego raczej nie wyświetla.
Offline
To się na dzień dobry uprzejmie naucz co oznacza te 94M (bo to wbrew Twemu radosnemu mniemaniu nie jest ilość miejsca zajmowana przez pliki). Dla /var/log powinno być 4096, większa wartość to już powód do niepokoju, a 94000000 to masakra.
Offline
Dla /var/log powinno być 4096, większa wartość to już powód do niepokoju
E tam powód do niepokoju... ale jeśli ten link katalogu ma 94M, to on chyba jest troszeczkę rozrośnięty i ciekawe jak bardzo pofragmentowany xD Ja sobie zrobiłem 237.165 plików, i testowy link z 4K zwiększył objętość do prawie 5M, to jak tam jest 94M... xD Choć to też jeszcze nic nie oznacza, no bo:
The initial allocation equals the size of one sector, but can grow above that if necessary. Once allocated, space is not freed if files are removed, to reduce fragmentation.
Jak system mieli przy poleceniu ls i nie ma przy tym bad bloków, to ja obstawiam ilość plików w tym /var/log/ . Tam na listingu fsck jest 1.155.884 . Jeśli nie idzie sprawdzić zawartości /var/log/ to sprawdź zawartość pozostałych i będziesz wiedzieć ile tam w /var/log/ siedzi plików.
Także chciałeś mieć więcej logów, to masz ale nie miej pretensji, że system muli. xD
Offline
Akurat w /var/log nie powinno być tysięcy plików luzem - od tego są katalogi archiwów i katalogi logów oddzielnych usług. Toteż powód do niepokoju jest.
Co do niezwalniania miejsca - dlatego poprzednio sugerowałem założenie katalogu na nowo.
Offline
OK przepraszam, pomyliłem polecenia z tym ls -ld
OK czyli narobiło się pełno śmiecia.
Próbowałem usunąć wszystkie logi z archiwami
rm /var/log/*.gz
bash: /bin/rm: Argument list too long
Ale sądząc po komunikacie to jakiś plik/pliki mają "śmieciowe" nazwy i przez to rm nie usuwa wszystkiego.
Jedyna rada to usunąć /var/log po czym założyć go na nowo pozakładać puste pliki dla logów i odpalić usługi?
Co mogłem to usuwałem, zmieniłem ilości plików dla logrotate (choć nie były to jakieś kosmiczne ilości), odpaliłem logrotate trochę pomieliło ale przeszło.
Przy czym nadal jest duża wartość dla ls -ld
ls -ld /var/log drwxr-xr-x 15 root root 98484224 Jun 15 10:07 /var/log
Czyli jeszcze śmieci są.
Ostatnio edytowany przez life (2015-06-15 10:16:20)
Offline
podawałem sposób - przeczytaj uważnie to co pisałem wcześniej.
niestety ta wartość już zostanie, dlatego /var/log będzie trzeba założyć na nowo.
a, jeszcze jedno.
po zrobieniu porządku w /var/log robisz
mv /var/log /var/dupa mkdir /var/log mv /var/dupa/* /var/log/ rmdir /var/dupa
bez konieczności zatrzymywania usług.
Ostatnio edytowany przez ethanak (2015-06-15 10:42:58)
Offline
rm /var/log/*.gz
bash: /bin/rm: Argument list too long
Ale sądząc po komunikacie to jakiś plik/pliki mają "śmieciowe" nazwy i przez to rm nie usuwa wszystkiego.
Przecie pisze, że zbyt długa lista argumentów jest, tj. zbyt dużo plików chcesz naraz usunąć.
Tu masz info jak usunąć te pliki jeden po drugim: http://www.stevekamerman.com/2008/03/deleting-tons- … ist-too-long/
Offline
@morfik: czym się różni porada z twojego linku od tego, co napisałem explicite parę postów wyżej? licznik nabijasz czy czytać nie lubisz?
Offline
OK dziękuję za pomoc.
Jak zwykle można na was liczyć :)
Dla potomności:
Po czyszczeniu zamulał jeszcze logrotate. Należało wyczyścić jego wpisy w /var/lib/logrotate/state troche tam było tego śmiecia i przez to długo wisiał.
Teraz wszystko śmiga jak malina.
Ostatnio edytowany przez life (2015-06-15 17:44:13)
Offline
Dla tych, którzy się zastanawiają, jak zoptymalizować te katalogi to jest dobra wiadomość. Okazuje się, że fsck ma do tego odpowiednią opcję.
Przykładowy katalog:
root@jaqen-hghar:/home/user# ls -al /mnt drwxr-xr-x 7 user user 12288 Jun 21 13:11 morfik2
Jak widać jest to trochę więcej niż ustawowe 4096 bajtów. Po zapuszczeniu fsck w poniższy sposób:
# fsck.ext4 -Dvf /dev/mapper/debian_laptop-home .... Pass 3A: Optimizing directories ....
Ten powyższy katalog teraz ma:
# ls -al /mnt drwxr-xr-x 7 user user 4096 Jun 21 13:11 morfik2
Zatem zamiast tworzyć na nowo katalogi i przenosić do nich pliki, lepiej zaciągnąć do tego fsck. xD
Offline
Fajne! Tyle że przy zamontowanym filesystemie chyba się nie sprawdzi?
Offline
To weź se odmontuj / na serwerze np. w Kazachstanie. Oczywiście bez zatrzymywania usług...
Ostatnio edytowany przez ethanak (2015-07-11 13:27:08)
Offline