# A frissítés után: a PHP-FPM és az összes worker újraindítása

> PHP-FPM újraindítása a PHP2Shell frissítés után: miért nem elég az új fájl, mely szolgáltatások számítanak, és hogyan ellenőrizze, hogy nem fut régi worker.

Forrás: https://phpsos.de/hu/php2shell/php-fpm-neustart/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A PHP-frissítés után újra kell indítania a PHP-FPM-et és az összes többi szolgáltatást, amely PHP-t tölt be. Az új fájlok a merevlemezen nem elegendők, amíg régi PHP-folyamatok futnak a memóriában. Csak az újraindítás után dolgozik a szerver a PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 vagy a szolgáltatója backportjának javított kódjával.

## Miért kell újraindítania a PHP-FPM-et

Egy csomagfrissítés a merevlemezen lévő fájlokat cseréli le. A már futó folyamatok azonban a régi programkódot már betöltötték a memóriába, és azzal dolgoznak tovább. A PHP-FPM, az Apache mod_php-val vagy a LiteSpeed a workereit gyakran napokig életben tartja.

A PHP2Shell esetében ez különösen fontos. A [CVE-2026-109619](https://phpsos.de/hu/php2shell/cve-2026-109619/) rés éppen azon az állapoton múlik, amely a kérések között ugyanabban a workerben megmarad. Egy régi kódú worker sebezhető marad, bármelyik verzió van a lemezen. A php.net szerint ezért minden workert és folyamatot újra kell indítani.

Egyes csomagkezelők a frissítéskor automatikusan újraindítják a szolgáltatásokat, mások nem. Ne bízzon ebben, hanem ellenőrizze az eredményt.

Egy tipikus kép a mindennapokból: a csomagkezelő azt jelenti, hogy „PHP frissítve“, a monitoring nem mutat hibát, a weboldal működik. Ennek ellenére a régi workerek továbbra is minden kérést kiszolgálnak, mert senki sem indította újra a szolgáltatást. Kívülről ez az állapot nem ismerhető fel. Ezért minden frissítéshez hozzátartozik a folyamatok indulási idejének ellenőrzése.

## Mely szolgáltatások töltenek be PHP-t?

| Üzemmód | Mit kell újraindítani | Tipikus parancs (a nevek disztribúciónként eltérnek) |
|---|---|---|
| PHP-FPM | minden FPM-szolgáltatást, telepített verziónként | `systemctl restart php8.3-fpm` vagy `systemctl restart php-fpm` |
| Apache mod_php-val | az Apache-ot | `systemctl restart apache2` vagy `systemctl restart httpd` |
| php-cgi | a hívó webszervert, illetve a FastCGI-wrappert | a beállítástól függően |
| LiteSpeed | a LiteSpeedet és az lsphp-folyamatokat | a LiteSpeed-kezelőfelületen vagy szolgáltatásán keresztül |
| FrankenPHP | a FrankenPHP szolgáltatást vagy konténert | `systemctl restart frankenphp` vagy a konténer újralétrehozása |
| Docker, Kubernetes | a konténereket új image-ből újra létrehozni | lásd [PHP javítása Docker-konténerekben](https://phpsos.de/hu/php2shell/docker-container-patchen/) |

A mod_php esetében: a frissítés magát az Apache-ot érinti, mert a PHP minden Apache-folyamatban benne van. Hogy miért különösen kényes ez az üzemmód, azt a [Miért a mod_php viseli a legnagyobb kockázatot](https://phpsos.de/hu/php2shell/mod-php-risiko/) oldal írja le. A LiteSpeedről a [LiteSpeed és LSAPI](https://phpsos.de/hu/server/litespeed/) oldalon talál részleteket.

## A PHP-FPM újraindítása: a parancsok

Először keresse meg a szerveren az összes PHP-szolgáltatást. A Plesk, a cPanel és más felületek saját PHP-szolgáltatásokat hoznak magukkal saját nevekkel; a lista ezeket is megmutatja.

```bash
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
```

Ezután minden megtalált PHP-szolgáltatást indítson újra, ne csak az elsőt:

```bash
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm      # ha telepítve van egy második ág
sudo systemctl restart apache2         # mod_php esetén; RHEL-család: httpd
```

A `restart`ot ajánljuk a `reload` helyett. A reloadnál a főfolyamat megmarad; ez konfigurációs változtatásokhoz való. Egy biztonsági frissítés után biztosra akar menni, hogy minden folyamat új.

> **Fontos:**
> Ha emellett átmeneti intézkedéseket is beállított, például `session.upload_progress.enabled=0` értéket vagy rögzített memóriahatárokat, ezek is csak az újraindítás után érvényesülnek. Egy újraindítás mindkettőt elvégzi egy lépésben.

## Az ellenőrzés, hogy nem fut már régi worker

Vesse össze a folyamatok indulási idejét a frissítés időpontjával. Minden parancs kizárólag olvasó.

```bash
ps -o pid,lstart,cmd -C php-fpm8.3     # unter RHEL: -C php-fpm
systemctl status php8.3-fpm            # a „Active: … since …“ sor
needrestart -r l                       # Debian/Ubuntu, ha telepítve van
```

Ha egy folyamat régebbi a frissítésnél, azt nem fogta el az újraindítás. Gyakori okok az elfelejtett második PHP-ág, egy hosting-panelből származó saját pool-szolgáltatás, vagy egy konténer, amelyet csak újraindítottak, ahelyett hogy az új image-ből hoztak volna létre. Hogy a helyes verzió fut-e, azt a [PHP-verzió és javítási állapot helyes ellenőrzése](https://phpsos.de/hu/php2shell/php-version-pruefen/) oldal mutatja.

## Az újraindítás dokumentálása

Szerverenként jegyezze fel a frissítés és az újraindítás időpontját. Ez a pillanat választja el azt az időt, amikor a szerver sebezhető volt, attól, ami utána jön. Egy későbbi nyomellenőrzéshez, a biztosítóknak és egy lehetséges GDPR szerinti bejelentéshez ez a legfontosabb vonatkoztatási pont. Őrizze meg emellett a szervernaplókat október 20-tól, ahogy a szakmai sajtó ajánlja.

Sok weboldalt kiszolgáló szervereken érdemes egy rövid táblázatot vezetni: szerver, szolgáltatás, PHP-verzió, csomagverzió, az újraindítás időpontja és a személy, aki újraindított. Így gyorsan feltűnnek a lefedettség hézagai, például egy elfelejtett pool, vagy egy tesztrendszer, amely senki jegyzékén nem szerepelt.

## Hogyan segít konkrétan a PHP SOS?

A [PHP-javítási szolgáltatás](https://phpsos.de/hu/leistungen/php-patch-service/) keretében a frissítést és az újraindítást összefüggő folyamatként vesszük át:

- **A szolgáltatások megállapítása:** Megtalálunk minden PHP-t betöltő folyamatot, a hosting-panelekből és konténerekből származókat is.
- **Ellenőrzött újraindítás,** Önnel egyeztetve megfelelő időpontban, a folyamatban lévő rendelésekre vagy űrlapokra tekintettel.
- **Utóellenőrzés,** hogy egyetlen folyamat sem régebbi a frissítésnél, és a weboldal normálisan válaszol.
- **Jegyzőkönyvezés:** verziók, csomagállapotok és újraindítási időpontok szerverenként.


## Gyakori kérdések

**Elég a systemctl reload a restart helyett?**  
A PHP2Shell esetében a restartot ajánljuk. A reload a workereket többnyire újraindítja ugyan, de a főfolyamat tovább futhat. A restarttal biztos lehet benne, hogy nem marad folyamat régi kóddal. A rövid megszakítással szemben világos igazolás áll.

**Újra kell indítanom az egész szervert a PHP-frissítés után?**  
Általában nem. Elég újraindítani az összes szolgáltatást, amely PHP-t tölt be: a PHP-FPM-et, mod_php esetén az Apache-ot, a LiteSpeedet, a FrankenPHP-t vagy az érintett konténereket. Az egész szerver újraindítása az egyszerű változat, ha bizonytalan abban, mely szolgáltatások használnak PHP-t.

**Újraindítja a tárhelyszolgáltatóm automatikusan a PHP-t a frissítés után?**  
Ez a szolgáltatótól függ. Kérdezzen rá konkrétan, hogy a javítás után újraindították-e az összes PHP-folyamatot, és kérje ennek írásos megerősítését.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)