Dotaz: Apache httpd nefunguje po aktualizaci na 2.2.6

[Andrej]

Ahoj, prosím o radu s následujícím problémem.

Na serveru jsem měl httpd (Apache) verze 2.x. (Nevím už přesně, která verze to byla.) Server bez problémů fungoval, včetně PHP a přístupu k databázi.

Po aktualizaci (balíčkovacím systémem ArchLinuxu) na verzi 2.2.6 přestal fungovat. Jakýkoliv dotaz způsobí zatuhnutí démona se 100% využitím CPU.

Web tedy samozřejmě nefunguje a každý další pokus o načtení www stránky spustí další proces httpd, který opět využívá CPU, jak nejvíc může.

Po zamrznutí jsou procesy httpd nesmrtelné. Nelze je zabít žádným způsobem kromě restartu. Zdůrazňuji, že nejde o zombie procesy. Tyto využívají procesor velmi náruživě.

V logu nic podezřelého není. Možná bych měl zapnout jinou úroveň logování... Ale kterou?

Googlem jsem našel desítky odkazů o zamrzajících procesech httpd, ale vždy šlo o zombie nebo chybný PHP skript. Toto je zjevně jiný případ. Nemám ponětí, čím to může být.

Odpovědi

[frEon]

k tomu logovani, je to LogLevel debug
dela to u vsech virtualhostu? zkousel jsi i nacist sranku bez jakehokoliv php, mysql nebo jinejch skriptu?

[Andrej]

Zkusím tedy LogLevel debug. Zatím to vypadá, že se do logu nepíše absolutně nic, ale třeba se tam při vyšším LogLevelu stihne ještě něco zapsat, než to zamrzne.

Týká se to všech virtual hostů. I těch, u kterých není PHP.

[Andrej]

Tak teda fakt nevím, čím by to mohlo být. Zapnul jsem LogLevel debug. Tvrdilo to jedinou podezřelou věc - že vypršela platnost CRL. Tedy jsem vygeneroval nový CRL a hláška tam už pak není.

Ale zamrzá to dál přesně stejně. Do access_log se vůbec nic nezapíše, resp. nestihne zapsat. V error_logu taktéž nic zajímavého není. Jediná hlášení typu error vznikají ve chvíli, kdy se při restartu server vypíná a nemůže žádným způsobem zabít své zaseknuté potomky.

Takže co s tím? Přece nemůžu být jediný, kdo má tenhle problém... To by byla moc velká náhoda.

[vasek125]

df
cat /etc/hosts
cat /etc/resolv.conf

Nebude tam někde bordel? Zkoušel jste nedistribuční apache?

[Andrej]

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda1              3937220   1763492   1973724  48% /
none                    144108         0    144108   0% /dev/shm
/dev/hda2             15314684  11207300   3329440  78% /home
/dev/hdc1              5699964   1153176   4257244  22% /var

127.0.0.1       localhost.localdomain   localhost       charon

nameserver 127.0.0.1

Pro úplnost ještě dodám, že nastavení je přesně stejné jako u původní verze Apache, která fungovala. Na tom serveru zároveň běží named pro mou doménu, proto je sám sobě name serverem. (DNS funguje bez potíží.)

Jakmile ale přijde jakýkoliv http požadavek - bez ohledu na to, zda z vnitřní sítě nebo zvenčí - celý Apache se zasekne a nepomůže nic jiného než restart.

Už jsem měl podobný problém dvakrát. Jednou šlo (matně si vzpomínám) o problém s interpretem PHP (vyřešeno). Podruhé byl problém s šifrovacím enginem - špatný název souboru s klíčem (vyřešeno). Jenže v obou případech tam zůstávaly jen zombie, které nevyužívaly procesor. Tento případ je naprosto ojedinělý a asi kvůli němu brzy přijdu o nervy...

[Andrej]

Nedistribuční apache jsem nezkoušel. (Kdysi ano, ale tuto verzi nikoliv.) Je poměrně složité to správně nakonfigurovat a v tuto chvíli na to nemám čas ani kuráž. Kdybych jenom převzal konfiguraci z PKGBUILDu, získal bych stejný Apache... Jedině bych mohl někde splašit starší verzi, ale tím ten problém nezmizí.

[Filip Jirsák]

Jste si opravdu jist, že to není chybný PHP skript nebo nějaký problém s přepisováním adres? Odhadoval bych, že problém je v tom, že se Apache pokouší rekurzivně vkládat do sebe jednu a tu samou stránku, nebo se přesměrovává neustále na jednu a tu samou adresu (případně navzájem mezi více adresami v kolečku). Neaktualizovalo se s Apachem i PHP? Konfigurační soubory se změnily, nebo jsou tam stále ty samé?

Zkusil bych nejprve vyloučit problém se skriptem nebo přesměrováním – vypnout všechny rewrite a zkusit načíst nějakou statickou stránku. Pak můžete postupně začít přidávat – rewrite, PHP skripty…

[Andrej]

Jste si opravdu jist, že to není chybný PHP skript nebo nějaký problém s přepisováním adres?

Aktualizoval jsem pouze software. Skripty zůstaly navlas stejné. Fungovaly předtím cca půl roku. Pokud jde o mod_rewrite, nic takového nepoužívám.

Odhadoval bych, že problém je v tom, že se Apache pokouší rekurzivně vkládat do sebe jednu a tu samou stránku, nebo se přesměrovává neustále na jednu a tu samou adresu (případně navzájem mezi více adresami v kolečku).

To si nemyslím. Ani LogLevel debug neukazuje nic podezřelého nebo snad cyklického... Kdyby třeba narůstala spotřeba paměti nebo kdyby se hodně logovalo, dá se z toho kdeco usoudit. Jenže ono nic. Jen procesor je zatížený na maximum. Jednou se mi hromadily instance httpd proto, že selhal jeden z harddisků a nešlo zapisovat do logu. Ale toto není ten případ.

Neaktualizovalo se s Apachem i PHP? Konfigurační soubory se změnily, nebo jsou tam stále ty samé?

PHP se aktualizovalo taktéž. PHP (prostě přímo příkaz php) funguje - nechybí žádné knihovny nebo tak něco. Konfigurační soubory jsou původní. Časem se chystám provést nějaký merge, ale to bude dlouhá a nepříjemná procedura...

Zkusil bych nejprve vyloučit problém se skriptem nebo přesměrováním – vypnout všechny rewrite a zkusit načíst nějakou statickou stránku.

Provedeno. Přepisování nepoužívám. Mám hned několik virtuálních hostů se statickými stránkami. Bohužel taktéž nefungují. Dopadne to stejně, ať přistupuju ke stránce s PHP nebo bez něj.

[Filip Jirsák]

Aktualizoval jsem pouze software. Skripty zůstaly navlas stejné. Fungovaly předtím cca půl roku. Pokud jde o mod_rewrite, nic takového nepoužívám.

To by něco znamenalo, pokud by to nebylo PHP. S PHP si ale člověk nemůže být nikdy jistý, bohužel. Zvlášť když jste aktualizoval i PHP, tam co verze, to originál…

Provedeno. Přepisování nepoužívám. Mám hned několik virtuálních hostů se statickými stránkami. Bohužel taktéž nefungují. Dopadne to stejně, ať přistupuju ke stránce s PHP nebo bez něj.

Nemůžete mít zapnuté nějaké include nebo něco podobného? I z toho, že jsou všechny procesy ve stavu R bych tipoval, že ty procesy na nic nečekají, ale opravdu se snaží něco (cyklicky) načítat. Zkusil jste se připojit k serveru přímo telnetem a podívat se, jestli alespoň něco odpoví?

telnet server 80
GET / HTTP/1.0
Host: virtualhost.example.com
<Enter>
<Enter>

[Michal Kubeček]

Jestli to nejsou zombie, ale přesto nejdou zabít ani signálem KILL, pak jsou nejspíš ve stavu D. Pokud vám procesy zůstávají viset v tomto stavu, znamená to obvykle buď hardwarové problémy nebo chybu v jádře. Neupdatoval jste současně s Apachem i jádro?

[Andrej]

Jádro jsem updatoval až po Apache. (Právě kvůli takovému podezření.) Jenže před updatem i po něm to bylo stejné. Příkaz top ukazuje, že zamrzlé procesy jsou ve stavu R. Z nějakého důvodu je ovšem nelze zabít ani pomocí kill -9.

PID  USER      PR  NI  VIRT  RES  SHR S %CPU %MEM   TIME+   COMMAND
4035 nobody    25   0 21228 8372 2276 R 99.4  2.9   0:25.39 httpd

S každým dalším HTTP dotazem přibude další httpd. (Až do maximálního počtu procesů, které smí httpd vytvářet.) Procesor si mezi sebou dělí spravedlivě, avšak bezúčelně.

Předejdu i další možné otázce: Memtest jsem nechal běžet 9 hodin. Nenašel žádnou chybu.

[Michal Kubeček]

Pokud je nějaký proces ve stavu R a nezlikviduje ho 'kill -9', pak IMHO není problém v tom procesu.

[Andrej]

Možná není problém v procesu, ale pořád nevím, v čem by být mohl. Ty procesy jsou potomky jednoho httpd - nejspíš toho, který se spustil první. Ten se nezablokuje. Při restartu napřed zkouší zabít své zablokované potomky a zapisuje to do logu. Třikrát pošle SIGTERM. Když to nepomůže, pošle SIGKILL. Jenže ani ten nepomůže. (Tak prostě zůstanou běžet a přežijí dál.) (Zabíjení pomocí kill samozřejmě taky nepomáhá.)

[Michal Kubeček]

Asi jsem to ještě pořád nenapsal dost srozumitelně, tak to zkusím ještě jednou: pokud signál KILL nezlikviduje proces ve stavu R, je to chyba jádra. I kdyby se proces stavěl na hlavu, signál KILL ho prostě musí zabít bez ohledu na to, co on si o tom myslí. Takže nemůžu vyloučit, že je nějaká chyba v Apachi, ale zcela jistě to není chyba jen v Apachi.

[Andrej]

Je to pravda. Týká se to i Courier-MTA, jak jsem zjistil. Problém není v Apachi, ale v novém distribučním kernelu. Vždy o důvod víc, proč si zkompilovat vlastní. Teprve během dneška jsem našel tohle. (Jinak bych tu s tím neotravoval.)

Zkusím zkompilovat vlastní kernel nebo sehnat starší a pak se uvidí. Předpokládám, že tím problém prostě zmizí.

Chyba v kernelu je to poslední, na co bych býval vsadil, ale asi už to tak bude...

[Michal Kubeček]

Problém není v Apachi, ale v novém distribučním kernelu. Vždy o důvod víc, proč si zkompilovat vlastní.

To není tak jednoznačné. Distribuční jádra jsou obecně testována více než vanilla a při současném vývojovém modelu řady 2.6 to platí dvojnásob (zejména u 2.6.x). Samozřejmě se může stát, že distribuční patche zavlečou do jádra chybu, která ve vanilla stromu nebyla, ale obráceně je to pravděpodobnější.

[Andrej]

Konkrétně u ArchLinuxu bych nesázel na to, že distribuční jádra budou lepší než Vanilla...

[vasek125]

Tak to opravu vypadá na problém s apachem. Ale stejně se zeptám, nebyl ten počítač násilně vypnut? Jste si jistý, že php skripty mohou běžet na upgradovaném sw? Např. nějaká drobná změna s aktualizací, jako že třeba program není zkompilován s parametry jako předtím. Ještě bych zkusil jednu věc, aby se opravdu vyloučilo jiné zavinění, a to zpětný downgrade apache a hned budeme moudřejší.

[Andrej]

Násilně vypnut byl mnohokrát. Pak byl vždy nabootován z CD a proveden e2fsck na všechny oddíly.

PHP skripty neobsahovaly nic nekompatibilního nebo zastaralého. Kromě toho nefungují ani statické stránky.

Asi ten downgrade budu muset udělat, i když se toho poněkud děsím... Nic jiného prostě nezbývá. Jenže kdyby to byl opravdu nový problém s Apachem, už by toho byl plný Google... Jenže ono pořád nic.

[cooler]

A nevytvara niekdo hromadu poziadaviek na tento server ? Skusil by som apache pustit na inom porte na skusku.

[Andrej]

Tím to zcela jistě není. Teď to ale vypadá, že problém je (resp. brzy bude) vyřešen.