HELP! apache AH00052: child pid exit signal Segmentation fault (11)
Pavel Kankovsky
peak na argo.troja.mff.cuni.cz
Sobota Červen 20 13:11:18 CEST 2020
On Wed, 17 Jun 2020, Petr Stehlík wrote:
> upgradoval jsem mnoho let spolehlivě běžící LAMP server z Jessie na
> Stretch a hned poté na Buster. Pět dní všechno vypadalo dobře, ale šestý
> den 15 minut po půlnoci začal apache padat na Segmentation fault. Na
> každý požadavek na jakýkoliv web z těch mnoha hostovaných vždy okamžitě
> spadlo to pro onen požadavek forkované dítě.
>
> Pomohl restart celého apache. Vydrží běžet necelý den (výjimečně i
> několik dní). Většinou pár desítek minut po další půlnoci začne znovu
> padat. Myslel jsem si, že to souvisí s logrotate, který přesně o půlnoci
> reloaduje apache, ale ne - už jsem viděl začít padání i odpoledne, když
> jsem s ním hodně laboroval.
Budu předpokládat, že používáte prefork a mod_php.
Je dost zajímavé, že začnou ti potomci padat hromadně. Normálně by měly
být jejich držkopády nezávislé, když spadne jeden, tak by ho hlavní proces
by měl restartovat a tím by to bylo vyřešeno.
Pokud ale začnou padat všechny, tak by to naznačovalo, že je shnilého
něco, co je všem potomkům společné a co se nespraví jejich restartem:
možná je nahnilý hlavní proces, možná je to problém s nějakou sdílenou
pamětí. Nebo to možná nějak souvisí se zpracovávanými požadavky (přijde
vlna požadavků určitého charakteru a poshazuje to).
> Google tento druh pádů najde, ale lidi to řešili před 10-15 lety, a
> většinou za to mohla chyba v tehdejším PHP. Nic za poslední roky jsem
> nenašel, co bych mohl nějak aplikovat na moji situaci nebo použít
> nějaké řešení.
Myslím, že hlášení podobných problémů s PHP se objevují i pozdější době.
Jestli platí můj předpoklad o tom mod_php, tak jedna možnost je zkusit
změnit koncepci a přejít třeba na FastCGI tj. php-fpm. Když už nic jiného,
tak pak bude vidět, zda padá sám Apache nebo zda to dělá PHP.
> Zkoušel jsem měnit velikost paměti pro PHP (nepomohlo), zkoušel jsem se
> pomocí GDB připojit k apache a vidět pád (nepodařilo se mi to, neumím
> vidět to forknutí ani s "set follow-fork-mode child"), zkoušel jsem
> změnit LogLevel z warn na debug, ale v logu nic užitečného nevidím.
Odchytit, proč to spadlo, by fakt pomohlo.
Nenapadá mne, kde je problém s tím debuggerem, ale interaktivní ladění
podobných procesů je obecně potíž. Ale možná by pomohla post-mortem
analýza nějakého coredumpu, akorát se to musí povolit. Případně zkusit
mod_backtrace nebo něco podobného.
> Mám ještě i další servery - LXC hostitele se Stretchem, kde běží
> 64bitový kontejner s Busterem a LAMP a tam taky všechno běží OK. Tak že
> by problémy nějak souvisely s 64bit hostitel - 32bitový _BUSTER_
> kontejner? Už opravdu nevím, čeho se chytit.
To opravdu může být nějaká věc související s architekturou.
--
Pavel Kankovsky aka Peak "Que sçay-je?"
Další informace o konferenci Linux