Debian 4.0, Apache2
Egy érdekes hibajelenséggel találkoztunk a napokban.
Böngészés közben szerverünk üres lapokat ad vissza. Miután frissítem az oldalt, bejön a tartalom. Kattintok egy linkre mondjuk, és újból üres oldal jön be. Refresh, és megint jó minden...
Ha a szerveren újraindítom az Apache -ot, akkor pedig eltűnik ez a hibajelenség, és minden jó.
Találkozott már valaki hasonló jelenséggel, vagy van esetleg valakinek valami ötlete, hogy mi okozhatja ezt?
Előre is köszönöm!
- 2778 megtekintés
Hozzászólások
Nézted az apache error logját (keress segfault -ra rá)?
PHPs oldalak amik elhalnak?
- A hozzászóláshoz be kell jelentkezni
Természetesen néztem a LOG-okat, de semmi használható nincs benne.
Amit még érdemes megemlíteni és az előbb lemaradt: 30 percenként reload van. Nem restart! Csak simán reload, hogy az időközben történt változások aktiválódjanak.
- A hozzászóláshoz be kell jelentkezni
Emeld magasabbra a loglevel -t.
- A hozzászóláshoz be kell jelentkezni
Beállítottam debugra. Vagy mire gondoltad?
Mit figyeljek majd a LOG-okban? :)
- A hozzászóláshoz be kell jelentkezni
Bocsi, ezt nem ertem... miert 30 percenkent, miert nem azonnal ha valtozas van?
- A hozzászóláshoz be kell jelentkezni
Először az adatok nem közvetlenül konfig fájlokba kerülnek, hanem adatbázisba.
Fél óránként fut a script:
- bind konfig generálás adatbázisból
- bind reload
- apache2 konfig generálás adatbázisból
- apache2 reload
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy hülyeség: de ha két szerver között osztod a terhelést DNS-sel, akkor lehet, hogy az egyik bejegyzésben hiba van... (?)
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
Hámámé? Mi változik, ami miatt újra kell olvastatni a httpd.conf tartalmát?
- A hozzászóláshoz be kell jelentkezni
mondjuk virtális hosztok?
- A hozzászóláshoz be kell jelentkezni
és ez mivel jobb a módosítás utáni restartnál?
- A hozzászóláshoz be kell jelentkezni
Nem ez a gond elsősorban. A leállást, de akár csak "döccenést" okozó beavatkozások, production környezetben -hogy is fogalmazzak- nem illendőek ilyen sűrűn, napi egy alkalom is bőven elég kell, hogy legyen, pláne hogy ez maximum annak az n. darab új vhost-ot használónak jelent átlagosan fél napos késedelmet, az összes űgyfél napi negyvennyolcszori döcögtetése helyett...
- A hozzászóláshoz be kell jelentkezni
Ez a jelenseg az osszes kliensen van?
Bongeszo cache torlese?
lap ervenyesegi ido? cache expired....
- A hozzászóláshoz be kell jelentkezni
Nekem akkor jatszott ilyet, ha /var alatt elfogyott, vagy nagyon keves volt a hely. Fogadta a kapcsolatokat, idonket beadta az oldalakat, idonkent nem, csak zarta a kapcsolatot.
- A hozzászóláshoz be kell jelentkezni
Engem már a MySQL is szivatott meg így! Nem megy, nem megy... Aztán kiderült, hogy nincs hely a partícióján.
Nem mondom, hogy hű de sok hely van, de azért a 9GB szerintem kevésnek se mondható, tehát nem ez a helyzet! :(
- A hozzászóláshoz be kell jelentkezni
És a root-nak fenntartott hely mennyi? Default asszem 5% szokott lenni. Simán lehet, hogy httpd user már nem kap szabad helyet.
- A hozzászóláshoz be kell jelentkezni
Ezt most nem teljesen értem... Semmi kvótázás nincs a lemezen, senkinek incs fenntartott hely. Ha van hely, akkor van, ha nincs, akkor nincs! Vagy most mi van?
- A hozzászóláshoz be kell jelentkezni
-m reserved-blocks-percentage
Specify the percentage of the filesystem blocks reserved for the super-user. This avoids fragmentation, and allows root-owned daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem. The default percentage is 5%.
- A hozzászóláshoz be kell jelentkezni
Pl. ha van egy 100 GB -os file rendszered és mikor létrehozad az alapértelmezett mkfs.ext3 opciókkal,akkor ebből a 100 GB -ből 5% a root felhasználónak lesz fentartva, jelen példa esetében 5 GB. Szóval ha a root user -al azt látod, hgy ahh semmi gond van még 3 GB szabad hely, akkor az kellemetlen lehet,mert annyi már csak a root -nak van, más felhasználó (pl. apache) már azt látja, hogy out of space....
--
http://laszlo.co.hu/
- A hozzászóláshoz be kell jelentkezni
Igen, igen, közben már rájöttem, hogy mire gondoltok.
Nagyjából 30GB-os a partíció. Ennek az 5%-a 1,5GB. Szóval ha van szabadon 8-9 GB (rootként nézve), akkor szerintem annak elégnek kellene lennie!
- A hozzászóláshoz be kell jelentkezni
az "üres oldal" mit jelent?
ha telnet-tel (v. wget -d-vel) nézd mit mond ilyenkor az apache?
- A hozzászóláshoz be kell jelentkezni
Az az érdekes, hogy ez a jelenség a hajnali időszakban szokott előfordulni.
Az utolsó ilyen időszak az ma hajnalban volt 2:20 és 6:00 között... Ilyenkor meg ugyen inkább alszik az átlagos ember! :) Én legalábbis igen. Szóval nem tudom, hogy ilyenkor mit mond(ana), de lassan asszem éjszakáznom kell egy jót!
- A hozzászóláshoz be kell jelentkezni
Logrotate?
- A hozzászóláshoz be kell jelentkezni
Két kép, ha esetleg segít!
Csak úgy illetve ugyanaz a kép, csak pirossal kiemelve
- A hozzászóláshoz be kell jelentkezni
Loglevel átírása után a következő hiba olvasható az error.log -ban:
[info] server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 16 children, there are 0 idle, and 43 total children
Ez eddig nem volt, és mi ez a hiba? Most teljesen jól működik a rendszer egyébként...
- A hozzászóláshoz be kell jelentkezni
Összesen 43 szerver nagyon kevés egy publikus szerveren.
Most arra tippelnék, hogy éjjel a keresők robotjai pásztázzák a szervert akár sok szálon is. A nemzetközi kapcsolatod valószínűleg lassú és sokáig tartanak a kérések, tehát fogják az összes apache szálat.
Amúgy egy rendes szerveren 430 apache process jobb lenne, mint 43. De inkább mégtöbb.
- A hozzászóláshoz be kell jelentkezni
Ez iegy igen érdekes dolog...
Jelenleg egyébként 200 a limit, nem 43. És nem is értem, hogy ez az érték honnan jön... Nem mindig ezek az értékek szerepelnek a hibaüzenetben, hanem ez változó. A hibaüzenetet nem írom le újból, csak de pár értéket azért beírnék a LOG-ból.
spawing: 8 16 16 16 8 8
idle: 0 0 0 3 0 0
total: 57 65 34 30 22 24
- A hozzászóláshoz be kell jelentkezni
A dolog kicsit vicces... Na jó, nem vicces, hanem siralmas. És nem is kicsit, hanem nagyon.
Eddig a külföldi sávszélesség 256kbit volt! Nem elírtam, igen jól látja mindenki!! 256kbit ~ 32kbájt/s.
Ez igencsak kicsapta a biztosítékot nálunk, nem kis alkudozás árán sikerült végül 1mbit külföldet kikönyörögni, meglátjuk, hogy segít e...
- A hozzászóláshoz be kell jelentkezni
nagy proci igényű backup nem fut ilyenkor?
- A hozzászóláshoz be kell jelentkezni
Kevés lesz az Apache processzek száma, ha jól fordítom a hibaüzenetet (r=1 admin, aki nem olvassa el/értelmezi a hibaüzenetet :-P)
- A hozzászóláshoz be kell jelentkezni
Köszi szépen a fordítás, meg az értelmezés megy nekem is. Csak nem értem a hiba okát...
- A hozzászóláshoz be kell jelentkezni
Fut backup, és gondoltam erre én is. De megnézve a statisztikát: 12%-os CPU terhelés miatt szerintem nem kellene meghülyülnie. Ráadásul minden hajnalban fut a backup, a hiba viszont össze-vissza jelentkezik, nem rendszeresen. Tehát én ennek a lehetőségét kizártam.
- A hozzászóláshoz be kell jelentkezni
csak egy kerdes. biztos, h az apache?
nalam is neha elofordul, de erdekes modon csak Vista+IE7 kombon, XP+FF-on soha.
- A hozzászóláshoz be kell jelentkezni
[info] server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 16 children, there are 0 idle, and 43 total children
Ezen hibaüzenet szerint az a baj, hogy elfogytak az apache processek.
- A hozzászóláshoz be kell jelentkezni
Esetleg áttérni mpm-worker-re?
PHP-t meg fastcgi-vel használni?
- A hozzászóláshoz be kell jelentkezni
De azt azért tisztázzuk, hogy ez a hibaüzenet most van a logokban, mikor minden jól működik! Az oldalak rendesen bejönnek, ahogyan kell. Látszólag minden rendben! Tehát az "igazi" hiba lehet teljesen más miatt is!
Az üres lapos hiba még nem jelentkezett, mióta érzékenyebbre állítottam a LOG-olást. Tehát még azt se tudom, hogy olyankor milyen hibaüzenet van (lesz) a LOG-okban.
- A hozzászóláshoz be kell jelentkezni
Nomostan hány virt. domaint szolgál ki a vas, mekkora az hibát közvetlenül megelőző időszak webes forgalma, etc, etc, etc...
- A hozzászóláshoz be kell jelentkezni
377 domain név (829 host). Ezek közül nincs mindegyik beállítva, sőt sok domain alatt tartalom sincs, csupán erre a szerverre mutat.
Korábban küldtem két fájlt. Ezeket láttad? Vagy nem sok hasznos infóval szolgálnak?
http://djsilas.shellserver.hu/apache/nem_jelolt.jpg
http://djsilas.shellserver.hu/apache/jelolt.jpg
- A hozzászóláshoz be kell jelentkezni
Ez a drót forgalma, látszik, hogy leesik... A webszerverre érkező kérések száma mennyi, honnan, merről érkeznek...
- A hozzászóláshoz be kell jelentkezni
Legfelső ábra: Apache Accesses (80-as porton)
Plugin to monitor the number of accesses to Apache servers. It handles a list of ports passed in from a plugin configuration file.
Ha jól fordítottam, ez pont hogy az apache hozzáféréseket monitorozza.
Középső ábra: Apache activity
Ez igazából a http://domain-neved.hu/server-status oldalon kapott értékek ábrája.
Alsó ábra: Apache Processess
Plugin to monitor the number of apache-processes running on the machine, and (in addition to a simple process count), separate then into "busy" or "idle" servers.
Ez meg ha jól fordítottam, azt mutatja, hogy hány apache folyamat fut a szerveren, külön választva a foglaltakat, és a várakozókat.
- A hozzászóláshoz be kell jelentkezni
Ha esetlegvalakit érdekel, vagy hasonló problémával találkozna. Az apache konfigban jelenleg ezek az értkéke szerepelnek:
StartServers 5
MinSpareServers 5
MaxSpareServers 15
MaxClients 250
MaxRequestsPerChild 150
ServerLimit 250
Az error.log -ból eltűnt a korábban emlegetett hiba. Na jó nem teljesen, óránként azért 1x előfordul, de korábban jóval többször volt. Viszont csinálhatok bármit, teljesen nem tűnik el...
Az igazi, üres lapos hiba eddig nem jelentkezett újból. Mondjuk eddig se volt gyakori, de majd írok, hogy mi újság vele...
Minden esetre köszönöm az eddigi segítséget mindenkinek!
- A hozzászóláshoz be kell jelentkezni
Nem e Joomla-s weboldalrol van e szo OpenSEF komponensel?
Ha igen, akor meg kell patch-elni az OpenSEF-et. Egy nemet Joomlas forumon talaltam is egy mukodo patch-et, mar nem tudom hol, de ha kell privatban kuld a mailcimed es elkuldom.
Amugy mielott megtalaltam volna a patch-t sikerult nekem is megtalalnom a problemat. A sef.php-ben nem absolute path-el vannak includeolva mas php alomanyok es e miatt van a feher lap
_______________________________________________________
UBUNTU 8.04 Rock's!
Type cat vmlinuz-2.6.22-14-server > /dev/audio to hear the Voice of God.
- A hozzászóláshoz be kell jelentkezni
Nem nem, nem Joomlás oldalról van szó!
Ráadásul nem is csak egyről, több különböző oldalról van szó, azonos időben...
- A hozzászóláshoz be kell jelentkezni
Nekem is hasonló hibám van.Két debian-os gépen 4.0-ás debián van, és az első gépen péntek óta azt tapasztalom, hogy nem töltenek be teljesen a weboldalak. Az Opera mindig csak 16KB-t mutat. Arra is rájöttem, hogy ez a http oldalakra vonatkozik. Kiküld 16KB-ot, és ennyi. A log-fájlokban semmmi hiba.
Mától pedig a másik debian-os gépem halt be, ugyanez a hiba. Ha a html kisebb, mint 16KB, akkor semmi gond, ha nagyobb, akkor mintha késsel vágnák el a fájlokat, leállnak.
Mi lehet a hiba? Lehet ennek köze az apache szerver feltöréséhez? (én amúgy egyik gépen sem frissítettem semmit közvetlenül a hiba előtt, így aztán végképp nem tudom, miért most jött be ez a hiba)
- A hozzászóláshoz be kell jelentkezni
egyik ugyfel gepen hasonlo problemaba botlotam, kiderult hogy amit en firefoxban ures oldalnak latok az ieben megprobal egy virust letolteni, a problemat tovabb nyomozva kiderult
szokasos ftp jelszo lopasos modszerrel (totalcmdbol) egy php-t toltak fol
nem az edig megszokto iframe-os fertozest hanem egy php progit elrejtve egy alkonyvtarba, a php-t utana meghivtak tavolrol es post-tal atadtak neki egy binarist ami a memoriaban meg patchelte az apache-ot
mgb
- A hozzászóláshoz be kell jelentkezni
az szép, mik vannak.
a témaindítónak:
korábban nekünk is volt ilyen, jeleztem a rendszergazdának és elég hamar megoldódott a probléma. pontosan nem emlékszem már rá, de talán a DoS támadások elleni limitet kellett feljebb tolni, magyarul túl gyorsan kattintasz. persze ez csak tipp, lehet nálad máshol van a hiba.
- A hozzászóláshoz be kell jelentkezni