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/.

 Użytkownik
	

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



 Użytkownik
	






 Podobno człowiek...;)
	







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



 Użytkownik
	
 Użytkownik
	

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




 Zbanowany
	




1996
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:19:06)
Offline

 Użytkownik
	

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



 Użytkownik
	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







 Podobno człowiek...;)
	







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



 Użytkownik
	e tam - to można przez regexpa i -and -not zrobić :) szybsze będzie... tak mi się wydaje.
Offline

 Użytkownik
	

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



 Użytkownik
	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





 Cenzor wirtualnego świata
	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



 Użytkownik
	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





 Cenzor wirtualnego świata
	
 Użytkownik
	

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



 Użytkownik
	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





 Cenzor wirtualnego świata
	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



 Użytkownik
	@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





 Cenzor wirtualnego świata
	
 Użytkownik
	

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





 Cenzor wirtualnego świata
	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



 Użytkownik
	Fajne! Tyle że przy zamontowanym filesystemie chyba się nie sprawdzi?
Offline





 Cenzor wirtualnego świata
	


 Użytkownik
	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