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