Érthetetlen apache hiba (üres oldalak)

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!

Hozzászólások

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

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

Ez a jelenseg az osszes kliensen van?
Bongeszo cache torlese?
lap ervenyesegi ido? cache expired....

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.

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

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/

az "üres oldal" mit jelent?

ha telnet-tel (v. wget -d-vel) nézd mit mond ilyenkor az apache?

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!

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

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

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

nagy proci igényű backup nem fut ilyenkor?

csak egy kerdes. biztos, h az apache?

nalam is neha elofordul, de erdekes modon csak Vista+IE7 kombon, XP+FF-on soha.

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.

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

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.

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!

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.

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)

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

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.