Nahodne zabijeni procesu apache

Miroslav Lachman 000.fbsd at quip.cz
Mon Apr 11 23:23:13 CEST 2022


On 11/04/2022 18:02, Martin Stachura wrote:
> Dobrý den,
> 
> stava se mi, ze na serverech s FreeBSD 12.3 mi system zabiji procesy 
> apache a apache je neumi znovu vytvorit. 

To, ze system zabije nejaky proces signalem 10 nebo 11 se mi cas od casu 
nekde objevuje, ale nikdy to nevede k tomu, ze by si Apache nemohl 
vytvorit dalsi proces sam. Takze si tipuju, ze je neco shileho ve tve 
konfiguraci. U me je to jednoduche s tim, ze pouzivam MPM prefork a 
nahrazeni toho childu je asi jednodussi, nez to, co se musi stat v 
pripade MPM event

ale na vsech serverech pod FreeBSD s Apache

No i tohle smrdi nejakou chybou konfigurace.

>   php7_module (shared)

Jak uz zminil Dan, MPM event a PHP neni uplne dobra kombinace, 
respektive co jsem kdy cetl, neni to stabilni (nebo aspon nebylo v dobe, 
kdy jsem to cetl a protoze nemam potrebu tuhle kombinaci provozovat, tak 
se tim vic nezabyvam). Z minulosti si pamatuju, ze PHP musi byt 
kompilovano z portu se zapnutou volbou ZTS. Ta je ale defaultne vypnuta, 
takze jestli sis to nekompiloval sam a pouzil jsi balicek instalovany 
pres pkg install php74 / pkg install mod_php74 tak mas ZTS vypnute a to 
bude mozna i jadrem tohoto problemu. Nicmene co jsem tenkrat cetl, tak 
asi se ZTS to nebylo bezpecne provozovat, protoze ne vsechny extensions 
jsou ZTS kompatibilni.

Cimz se dostavam k jinemu problemu - v nekterych kombinacich Apache 
modulu a PHP extensions dochazi (dochazelo) k tem SIGBUS a SIGSEGV 
killum celkem pravidelne. Matne si vybavuju, ze mod_dav_svn se nesnesl s 
php-fileinfo, nebo necim takovym. Proste si clovek musel vybrat, jestli 
bude provozovat mod_dav_svn v Apache, nebo bude mit php-fileinfo 
extension v PHP. Oboje najednou neslo.
Obdobne signal 10 nebo 11 dokazala pravidelne delat extensio php-mime, 
pokud se jako zdroj mime dat pouzil konkretni soubor mime dat z Apache, 
i kdyz to bylo podle navodu. Kdyz jsem pouzil jiny zdroj mime dat, tak 
to fungovalo.
S MPM prefork se tyhle problemy projevuji jen tak, ze do browseru 
dostanes prazdnou stranku, nebo ERR_EMPTY_RESPONSE, ale Apache vytvori 
dalsi child a dokud nekdo nenavstivi znova tu samou problematickou URL, 
tak vesele bezi dal a forkuje dal.

Zkus se tedy podivat, jestli tvoje PHP ma zapnute ZTS. Pokud ne, buildni 
si to se ZTS, nebo prehod z MPM event na MPM prefork.

Mirek


More information about the Users-l mailing list