AH00288 cPanelen: miért telik meg az Apache scoreboard?
Egy Apache-kiesés első ránézésre sokszor egyszerű túlterhelésnek tűnik. Magas CPU-használat, elfogyó memória, túl sok párhuzamos kapcsolat vagy egy agresszív crawler mind kézenfekvő magyarázat lehet. Van azonban egy jóval kellemetlenebb eset: amikor maga az Apache folyamat fut, a rendszer szerint a szolgáltatás aktív, a 443-as port is elérhetőnek látszik, a weboldalak mégsem válaszolnak.
Pontosan ilyen hibát vizsgáltunk két külön cPanel szerveren. Mindkét rendszeren Apache 2.4 futott worker MPM-mel, és mindkettőn megjelent ugyanaz a ritkább, de annál beszédesebb hiba:
AH00288: scoreboard is full, not at MaxRequestWorkersA vizsgálat végére nem egyszerűen azt találtuk meg, hogy melyik Apache-paraméter módosítása segíthet. Logokból rekonstruálhatóvá vált az is, hogyan maradtak életben korábbi Apache-generációk graceful restartok után, hogyan jelentek meg velük párhuzamosan új worker folyamatok, és hogyan kapcsolódott ehhez a cPanel splitlogs rendszerének Broken pipe hibája.
Fontos azonban már az elején leszögezni: az általunk alkalmazott módosítás jelenleg mitigáció. Nem állítjuk, hogy minden AH00288 hiba mögött ugyanaz az ok áll, és azt sem, hogy egyetlen Apache-paraméter megváltoztatása minden környezetben végleges megoldást jelent.
Az első furcsaság: Apache futott, a web mégsem válaszolt
Az egyik incidens alatt a szolgáltatás állapota teljesen normálisnak látszott:
systemctl is-active httpd
activeEnnek ellenére egy közvetlen HTTPS-kérés már időtúllépéssel végződött.
Ez fontos különbség. Nem arról volt szó, hogy az Apache főfolyamata összeomlott vagy a systemd leállította a szolgáltatást. A processz létezett, a szolgáltatás active állapotban volt, miközben a tényleges webes kiszolgálás gyakorlatilag használhatatlanná vált.
Még érdekesebb volt, hogy a cPanel szolgáltatásfigyelője bizonyos időpontokban sikeresen kapcsolódott az Apache socketjéhez. Vagyis egy egyszerű TCP-kapcsolódási teszt átmehetett, miközben egy valódi TLS/HTTP kérés már nem kapott időben választ.
Ez az egyik oka annak, hogy Apache-problémánál önmagában a következő ellenőrzés kevés:
systemctl status httpdA szolgáltatás állapotát mindig érdemes tényleges HTTP- vagy HTTPS-kéréssel is ellenőrizni.
Mit jelent valójában az AH00288?
A hiba szövege elsőre paradoxnak tűnhet:
scoreboard is full, not at MaxRequestWorkersHa a szerver nincs a MaxRequestWorkers határán, hogyan lehet mégis tele a scoreboard?
Az Apache a scoreboard segítségével követi a gyermekfolyamatokat és worker szálakat. A graceful restartoknál különösen fontos ez a mechanizmus, mert a régi konfigurációhoz tartozó gyermekek nem feltétlenül tűnnek el azonnal.
Az Apache hivatalos graceful restart dokumentációja szerint graceful restartkor a parent process jelzi a gyermekeknek, hogy az aktuális kérésük befejezése után álljanak le, közben újraolvassa a konfigurációt és új generációhoz tartozó gyermekfolyamatokat indít. A scoreboardot generációkon keresztül fenn kell tartania, hogy a régi és új childok állapotát egyaránt követni tudja.
Ez normális működés. Problémává akkor válhat, ha a korábbi generációk egyes folyamatai hosszú ideig nem tudnak befejeződni.
Az Apache event MPM dokumentációja külön is leírja azt a helyzetet, amikor graceful restart után régi processzek tovább futnak, miközben az új generáció már elindult. Ilyenkor a régi processzek addig foglalhatják a scoreboard slotjait, amíg ténylegesen le nem állnak.
A logokban ténylegesen láttuk a generációk átfedését
A vizsgálat egyik legfontosabb eredménye nem egy konfigurációs érték, hanem a folyamatok idővonala volt.
Egy graceful restart például így jelent meg:
AH00297: SIGUSR1 received. Doing graceful restartNéhány másodperccel később:
AH00292: Apache/2.4.x configured -- resuming normal operationsEz önmagában teljesen normális.
A probléma az volt, hogy egy korábbi Apache-generációhoz tartozó child processzek a következő graceful restart után is életben maradtak. Egy konkrét esetben a 07:44 körül létrejött generációhoz tartozó folyamatok még 07:51 és 07:52 között is dolgoztak, miközben 07:50-kor már megtörtént a következő graceful restart.
Vagyis egyszerre volt jelen:
- a korábbi Apache-generáció,
- az újonnan létrehozott generáció,
- valamint több olyan régi worker, amely még kapcsolatokat próbált befejezni.
Ebben az időablakban jelent meg az AH00288.
Ez azért lényeges, mert már nem pusztán elméleti lehetőségként beszélünk régi worker-generációkról. A PID-ek és időbélyegek alapján a folyamatok átfedése a vizsgált rendszerben ténylegesen bizonyítható volt.
A splitlogs Broken pipe ugyanebben az időszakban jelent meg
A következő nyom az AH00646 volt:
AH00646: Error writing to |/usr/local/cpanel/bin/splitlogs
(32)Broken pipeA cPanel piped logging használatakor az Apache nem minden virtual host naplóját kezeli közvetlenül. A logbejegyzéseket egy közös csatornán keresztül a cPanel splitlogs programjához küldheti, amely aztán a megfelelő domainnaplókba szétválogatja őket.
Ennek komoly előnye van sok domaint kezelő szervereken. A cPanel kifejezetten ajánlja a piped logging használatát nagy számú domain esetén, mert így az Apache-nak kevesebb logfájlt és file handle-t kell közvetlenül kezelnie.
Csakhogy a cPanel 2026. május 19-i hivatalos dokumentációja külön leírja, hogy Apache graceful restartok és splitlogs használata mellett Broken pipe hibák jelenhetnek meg.
A cPanel szerint ennek hátterében egy ismert piped-logging race condition állhat több graceful restart során. A belső cPanel hibajegy azonosítója:
CPANEL-53462A cPanel az Apache Bug 61926 hibajegyre is hivatkozik.
A mi logjainkban a jelenség különösen látványosan jelent meg: régi Apache PID-ek próbáltak írni a splitlogs pipe-ba, miközben már új Apache-generáció futott.
Néhány másodpercen belül egymás mellett szerepeltek:
AH00646: Broken pipeés:
AH00288: scoreboard is full, not at MaxRequestWorkersEbből azonban nem következik, hogy a splitlogs tölti meg a scoreboardot. Ezt fontos különválasztani.
A bizonyítható állítás az, hogy ugyanannak a problémás graceful-restart időszaknak két tünetét láttuk: régi worker-generációk maradtak életben, miközben piped-logging hibák és scoreboard-kimerülés is jelentkezett.
Nem a MaxRequestWorkers volt kevés
Az ilyen hiba egyik könnyű félrediagnosztizálási lehetősége a MaxRequestWorkers egyszerű megemelése.
A hibaüzenet viszont éppen azt mondja:
not at MaxRequestWorkersA cPanel 2026. május 16-án kiadott hivatalos AH00288 support dokumentuma külön foglalkozik az AH00288 hibával worker MPM esetén. A cPanel szerint ilyenkor a worker child processzek kapcsolatkezelése és a MaxConnectionsPerChild értéke lehet releváns, és ideiglenes workaroundként ennek az értéknek a növelését javasolják.
A vizsgált rendszereken az érték eredetileg:
MaxConnectionsPerChild 10000volt.
Nem módosítottuk ezzel együtt a MaxRequestWorkers értékét. Egy változót akartunk egyszerre megváltoztatni, hogy később értelmezhető maradjon az eredmény.
A MaxConnectionsPerChild szerepe
A MaxConnectionsPerChild azt szabályozza, hogy egy Apache child process hány kapcsolat kiszolgálása után kerüljön újrahasznosításra.
A cPanel Apache-konfigurációs API dokumentációjában ez szintén támogatott paraméterként szerepel.
A cPanel által dokumentált workaroundot követve a két problémás szerveren ezt állítottuk:
MaxConnectionsPerChild 10000helyett:
MaxConnectionsPerChild 50000értékre.
Ez ötszörös növelés, ezért nem olyan paraméter, amit érdemes minden szerveren automatikusan ugyanígy módosítani. A megfelelő érték függhet a terheléstől, az Apache-konfigurációtól és az alkalmazások viselkedésétől.
A lényeg számunkra az volt, hogy a cPanel által dokumentált probléma irányába indultunk el, nem véletlenszerű Apache-tuningot végeztünk.
Egy érdekes cPanel-kompatibilitási részlet
A módosítás során belefutottunk egy további érdekességbe.
A jelenlegi cPanel dokumentáció a konfigurációs attribútumot:
maxconnectionsperchildnéven dokumentálja.
Az egyik régebbi cPanel-generációt használó gépen azonban a ténylegesen telepített Cpanel::EA4::Conf modul conf_attrs() listájában ez szerepelt:
maxrequestsperchildés ennek értéke:
10000volt.
Ez a régebbi Apache-elnevezésből maradt kompatibilitási sajátosság. A generált Apache-konfigurációban ugyanakkor már a modern direktíva jelent meg:
MaxConnectionsPerChild 10000A tanulság itt egyszerű: automatizált cPanel-konfiguráció módosítása előtt nem érdemes feltételezni, hogy minden cPanel-generáció pontosan ugyanazt a belső attribútumnevet használja.
Meg kell nézni, mit támogat ténylegesen az adott rendszer.
Miért nem szerkesztettük egyszerűen kézzel a httpd.conf fájlt?
cPanel szerveren a generált:
/etc/apache2/conf/httpd.confközvetlen módosítása rossz irány.
Egy következő konfiguráció-újragenerálás felülírhatja a változtatást.
Mi ezért a cPanel konfigurációs rétegében állítottuk át az értéket, majd újrageneráltuk az Apache-konfigurációt.
A végén mindig ellenőriztük a tényleges eredményt:
MaxConnectionsPerChild 50000és csak ezután következett az Apache újraindítása.
A WHM grafikus felületén ugyanez a beállítás a Global Configuration alatt található Max Connections Per Child mezőn keresztül módosítható. A cPanel saját AH00288 support dokumentuma is ezt az eljárást írja le.
Miért teljes stop/startot használtunk a végén?
Normál konfigurációváltoztatásnál a graceful restart előnye nyilvánvaló: a folyamatban lévő kérések lehetőség szerint nem szakadnak meg.
Ebben az incidensben azonban éppen a graceful restartok körül kialakuló régi és új Apache-generációk átfedését vizsgáltuk.
Ezért a módosítás aktiválásakor nem akartunk még egy újabb graceful generációt ráengedni a már eleve problémás állapotra.
Kontrollált karbantartási pillanatban teljesen leállítottuk az Apache-ot, ellenőriztük, hogy nem maradt korábbi httpd processz, majd tiszta generációként indítottuk újra.
Az Apache hivatalos dokumentációja szerint a TERM alapú stop a gyermekfolyamatok azonnali leállítására törekszik, szemben a USR1 graceful működésével, ahol az aktuális kérést kiszolgáló régi childok tovább élhetnek.
Ez természetesen rövid szolgáltatáskieséssel járhat, ezért nem általános újraindítási ajánlás. Ebben az esetben diagnosztikai szempontból fontos volt, hogy garantáltan ne maradjon korábbi Apache-generáció a memóriában.
Imunify360 és a graceful restartok
A vizsgálat során feltűnt egy másik összefüggés is.
A szervereken Imunify360 futott, és a saját naplója több alkalommal egyértelműen jelezte:
Performing web server graceful restartA restartok között szerepelt például:
create_rbl_whitelistés:
update_vendorsáltal kiváltott művelet is.
Az egyik kritikus incidensnél az Imunify360 által indított graceful restart után néhány percen belül megjelent a splitlogs Broken pipe, majd az AH00288.
Ez azonban megint nem jelenti azt, hogy „az Imunify360 hibás”.
Az Imunify360 dokumentációja szerint a rendszer webserver-integrációja eleve rendelkezik graceful_restart_script mechanizmussal, amelyet webserver-konfiguráció vagy ModSecurity-szabályok módosítása után használhat.
Az RBL whitelist létrehozása szintén dokumentált Imunify360 funkció.
A mi esetünkben tehát azt tudjuk bizonyítani, hogy az Imunify360 több graceful restartot kezdeményezett. Azt nem állítjuk, hogy önmagában az Imunify360 okozza az Apache scoreboard hibáját.
A problémát inkább úgy érdemes megfogalmazni, hogy egy olyan környezetben, ahol valamilyen automatizmus viszonylag gyakran indít graceful restartot, sokkal nagyobb jelentősége van annak, hogy az előző Apache-generációk milyen gyorsan tudnak ténylegesen leállni.
Miért nem tiltottuk le egyszerűen a splitlogs használatát?
A cPanel az AH00646 Broken pipe probléma workaroundjaként említi a Piped Apache Logs kikapcsolását.
Ez elsőre kézenfekvő megoldásnak tűnhet.
Mi azonban nem kapcsoltuk ki azonnal.
A cPanel Piped Log Configuration dokumentációja szerint a piped logging különösen hasznos sok domainnel működő rendszereken, mert csökkenti az Apache által közvetlenül kezelt logfájlok és erőforrások számát. A cPanel kifejezetten ajánlja ezt a működési módot nagy számú domain esetén.
Ezért egy több webhelyet kiszolgáló hosting szerveren nem feltétlenül jó megoldás egy ismert race condition miatt azonnal kikapcsolni az egész piped logging mechanizmust.
Először az AH00288 problémára dokumentált mitigációt alkalmaztuk, és egy változót módosítottunk.
Ha a hiba így is visszatér, a piped logging kérdése újra előkerülhet.
Nem CPU, nem memória és nem OOM
A vizsgálat során külön ellenőriztük, hogy az Apache-kiesés nem egy általános rendszerterhelési probléma következménye-e.
A problémás időszak kernelnaplóiban nem láttunk:
- OOM
- out of memory
- Killed process
- hung task
- nf_conntrack table full
- segfault
jellegű releváns hibát.
A rendszerterhelési adatok sem mutattak olyan CPU- vagy load-értéket, ami megmagyarázta volna a teljes HTTPS-elérhetetlenséget.
Az egyik kiesés idején például a load average jóval 1 alatt volt egy többprocesszoros rendszeren, miközben az Apache már nem szolgálta ki megfelelően a HTTPS-kéréseket.
Ez volt az a pont, ahol végleg el lehetett vetni azt az egyszerű magyarázatot, hogy „kevés a szerver”.
A rendszernek volt szabad számítási kapacitása. Az Apache belső processz- és kapcsolatkezelési állapota volt problémás.
A támadó forgalom sem magyarázott meg mindent
A vizsgálat idején természetesen rengeteg automatikus internetes scanner is érte a szervereket.
Láttunk többek között:
- /.env
- /wp-config
- /proc/self/environ
- /.ssh/
- Terraform state
- AWS credential
jellegű probe-okat.
Az egyik szerveren rövid idő alatt több száz kérés/másodperces burstöt is találtunk egyetlen forrásból.
Az ilyen forgalom természetesen növelheti a kapcsolatkezelési nyomást, és egy már rossz állapotban lévő Apache-ot könnyebben eljuttathat a hibáig.
De fontos különbség van kiváltó terhelés és alapvető mechanikai probléma között.
A scoreboard-generációs átfedés és a graceful restartok problémája akkor is létezhet, ha a konkrét támadó IP-t blokkoljuk.
Ezért nem elégedtünk meg azzal, hogy néhány agresszív címet firewall DROP listára tettünk.
A módosítás utáni állapot
Mindkét érintett szerveren végül:
MaxConnectionsPerChild 10000értékről:
MaxConnectionsPerChild 50000értékre váltottunk.
Ezután teljes Apache stop/start történt, hogy egyik korábbi generáció se maradjon életben.
Ellenőriztük:
- az Apache aktív állapotát,
- a tényleges HTTPS-választ,
- az új Apache PID-ek indulási időpontját,
- a splitlogs folyamatok újraindulását,
- a generált Apache-konfiguráció tényleges értékét,
- valamint az új AH00288 és AH00646 hibák megjelenését.
A friss generációk indulása után mindkét szerver megfelelően válaszolt, és közvetlenül az újraindítás után nem jelent meg új scoreboard- vagy Broken pipe hiba.
Ez jó eredmény, de még nem bizonyítja, hogy a probléma végleg megszűnt.
A valódi teszt a következő graceful restart
Az incidens kezelése itt nem ér véget.
A legfontosabb következő esemény egy automatikusan bekövetkező graceful restart lesz.
Akkor azt kell figyelni, hogy:
a korábbi Apache-generáció milyen gyorsan tűnik el,
jelenik-e meg ismét AH00646,
visszatér-e az AH00288,
és továbbra is stabilan válaszol-e a HTTPS-szolgáltatás.
Ha több graceful ciklus és normál forgalom után sem tér vissza a probléma, sokkal erősebben lehet majd kijelenteni, hogy a MaxConnectionsPerChild növelése hatékony mitigáció volt ebben a konkrét környezetben.
Lehet hosszabb távon jobb megoldás az event MPM?
A vizsgált rendszereken Apache worker MPM futott.
Érdekes további vizsgálati irány az event MPM.
Az Apache dokumentációja szerint az event MPM 2.4.24 óta több olyan fejlesztést tartalmaz, amely kifejezetten a graceful termination kezelését javítja. Többek között jobban képes kezelni a leálló processzek scoreboard használatát, és a dokumentáció konkrétan említi az „old gen” állapotú processzeket is.
Ez nagyon közel áll ahhoz a problémához, amit a saját logjainkban láttunk.
Ettől még hosting környezetben nem szabad vakon MPM-et váltani. Ellenőrizni kell a PHP-kezelés, a CloudLinux, az LSAPI, a telepített Apache-modulok és a cPanel adott verziójának kompatibilitását.
Az event MPM ezért nálunk jelenleg vizsgálandó stratégiai irány, nem azonnali incidenskezelési lépés.
Mit tanultunk az incidensből?
Az AH00288: scoreboard is full, not at MaxRequestWorkers nem feltétlenül egyszerű kapacitásprobléma.
Egy Apache lehet systemd szerint aktív úgy is, hogy a valódi HTTPS-kiszolgálás már gyakorlatilag működésképtelen.
Egy graceful restart pedig nem jelenti azt, hogy az előző Apache-generáció azonnal megszűnt.
A mi esetünkben logokkal bizonyíthatóan egymás mellett éltek régi és új worker-generációk. Ugyanebben az időszakban jelentek meg a cPanel által ismert splitlogs Broken pipe hibák és az Apache scoreboard telítődésére utaló AH00288 üzenetek.
A cPanel által dokumentált MaxConnectionsPerChild workaroundot ezért két érintett rendszeren is alkalmaztuk, 10000 értékről 50000 értékre emelve a limitet.
A legfontosabb tanulság azonban nem maga az 50000-es szám.
Hanem az, hogy ilyen hibánál nem érdemes egyetlen pillanatnyi metrikából következtetni.
A systemd állapot, a tényleges HTTP-válasz, az Apache error log, a child PID-ek életkora, a graceful restartok időpontja, a piped logging, az automatizált biztonsági rendszer restartjai és a rendszerterhelési adatok együtt mutatták meg, mi történik valójában.
És talán ez a legfontosabb különbség egy egyszerű újraindítás és egy valódi incidensvizsgálat között: az első visszahozza a szolgáltatást, a második esélyt ad arra, hogy legközelebb már ne ugyanott keressük a hibát.
Hivatalos dokumentáció
A vizsgálat során több hivatalos dokumentáció is alátámasztotta a logokból levont következtetéseket. A cPanel külön support dokumentumot tart fenn az AH00288: scoreboard is full, not at MaxRequestWorkers hibáról, amely worker MPM esetén a MaxConnectionsPerChild növelését ideiglenes workaroundként említi.
A cPanel külön dokumentálja a graceful restartok mellett jelentkező splitlogs Broken pipe race conditiont is, CPANEL-53462 belső hibajeggyel és Apache Bug 61926 hivatkozással.
Az Apache graceful restart dokumentációja részletesen bemutatja a scoreboard generációkon keresztüli fennmaradását, az event MPM dokumentációja pedig külön tárgyalja azokat az eseteket, amikor korábbi generációk processzei még graceful állapotban scoreboard slotokat foglalnak.
Az Imunify360 dokumentációja pedig megerősíti, hogy a webserver-integráció része a konfigurációs és ModSecurity-változások után meghívható graceful restart mechanizmus.