Fórumok
Sziasztok,
Az operációs rendszer Redhat 8, Tomcat verziója 9.0.65.
A probléma a következő:
Egy tomcat alkalmazás 2022.07.24 én még a logrotálás után leürítette a catalina.out tartalmát, de azóta nem.
Volt akkor egy tomcat frissítés és még utána működött, de viszont kézzel le lett ürítve a catalina.out (echo > " ") azóta úgy tűnik nem működik.
Esetleg van valakinek ötlete mi lehet a probléma?
A válaszokat előre is megköszönve
Hozzászólások
nem fogyott el a hely közben? logrotate szokott ilyenkor belepistulni, hogy nem volt sikeres a futás...
azt figyeljük monitoringgal is, 80 % szabad hely van. :-(
Az optimizmus nem azt jelenti, hogy valaki nem látja a problémákat, hanem hogy hisz abban, hogy mindig létezik egy megoldás.
Pontosan micsoda nem működik? Nem tudja átnevezni a logrotate a catalina.out fájlt? A könyvtár és vagy a fájl jogai változtak mostanában? Esetleg valami SeLinux-szerű megkönnyítőprogram nem járt arra?
(Ha rosszul áramlott benned a kí amikor a fájlt módosítottad, akkor a fájlnak is rossz lesz a karmája, és ez bizony sok bajjal járhat.)
"Nem tudja átnevezni a logrotate a catalina.out fájlt" - azt fogja a java processz, úgyhogy copytruncate kell a logrotate konfigba.
" kézzel le lett ürítve a catalina.out (echo > " ")" hmmm... getenforce? ls -lZ catalina.out ? audit2why?
1, Szerintem a Tomcat-nek sok köze nincs ahhoz, hogy valami valahol rotálja-e a logját, nem tud róla.
2, Bárhova megyek, ahol van Tomcat és nem cserélhető le valamiért, ott azzal kezdem, hogy ha bármi is megy a catalina.out fájlba, akkor az üzemeltetési kockázat.
3, Szóval: CATALINA_OUT=/dev/null + minden megy valami logger rendszerbe.
https://iotguru.cloud
Nem véletlenül van annak a nyamvadt java processznek az stdout-ja fájlba irányítva... Tapasztalat, hogy nem minden kerül bele a logba, ami az stdout-ra meg/még kimegy.
Hogy a copytruncate működik-e adott esetben, az jó kérdés, ha nem, akkor mélyebbenkell belemászni a motyóba, és az stdout-ot olyan szűrőbe beküldeni, ami önmagától képes a bemenetét naponta/x időnként új fájlba kiírni. Ez mondjuk azzal jár, hogy a csomagból települő scriptbe kell belemászni... :-(
Mondj már egy ilyen példát.
https://iotguru.cloud
Legvalószinübb persze hogy ráfog valami és amiatt nem engedi el a helyet. yum install psmisc,abban lesz a fuser command.Aztan fuser "fájlnév".Az kiirja mely processzek,pid-ek fogják a fájlt ha bármi is.ps -ef |grep PID és meg is van mi lockolja. Azt ha leállitod vagy csak restart akkor elengedi és felszabadul a hely.
A logrotate copytruncate opciója megoldja - elvileg. Ha nem, akkor a java-t ténylegesen hívó scriptbe kell belenyúlni, és a java processz standard kimenetét át kell futtatni egy, a logot önmagában rotálni képes szűrőn. Most nem találom, de van ilyen kész tool.
esetleg nem a cronolog az amire gondolsz?
a catalina.sh scriptbe kell egy vagy két sort módosítani, valamelyik 9-es tomcatbe megkönnyítették ez, majd valamiért vissza is vonták.
nagyjából így:
2>&1 |/usr/bin/cronolog "$CATALINA_BASE/logs/catalina-%Y-%m-%d.out" &
Jónak hangzik ez a cronolog, egyelőre két apróság tűnt fel: az első forrásból letöltve nem konfigurálódik, a másodikból meg valamiért a /usr/local/sbin-be települ (
--sbindir=/usr/local/binmegoldja.)A Debian/Ubuntu és a Fedora/CentOS/RHEL vonulat karbantartói csak meg tudták oldani valahogy :-) (ott látom, hogy van ilyen csomag)
Igen, ez az. Köszönöm.
Köszönöm a válaszokat.
Folytatom a megoldás keresését.
Üdv
Az optimizmus nem azt jelenti, hogy valaki nem látja a problémákat, hanem hogy hisz abban, hogy mindig létezik egy megoldás.
Amit zeller írt. A tomcat folyamatosan fogja a logfilet, ezért nem lehet simán rotálni, kell bele a copytruncate.