# След актуализацията: рестартиране на PHP-FPM и на всички worker процеси

> Рестартиране на PHP-FPM след актуализацията за PHP2Shell: защо новите файлове не стигат, кои услуги са важни и как да проверите, че не работи стар worker.

Източник: https://phpsos.de/bg/php2shell/php-fpm-neustart/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** След PHP актуализацията трябва да рестартирате PHP-FPM и всички други услуги, които зареждат PHP. Новите файлове на диска не стигат, докато стари PHP процеси работят в паметта. Едва след рестартирането сървърът работи с коригирания код на PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 или с backport-а на Вашия доставчик.

## Защо трябва да рестартирате PHP-FPM

Актуализацията на пакет заменя файловете на диска. Процесите, които вече работят, обаче са заредили стария програмен код в паметта и продължават да работят с него. PHP-FPM, Apache с mod_php или LiteSpeed често държат своите worker процеси живи с дни.

За PHP2Shell това е особено важно. Уязвимостта [CVE-2026-109619](https://phpsos.de/bg/php2shell/cve-2026-109619/) е свързана именно със състояние, което остава между заявките в същия worker. Worker със стар код остава уязвим, независимо коя версия лежи на диска. Според php.net затова всички worker и процеси трябва да се рестартират.

Някои пакетни мениджъри рестартират услугите автоматично при актуализация, други не. Не разчитайте на това, а проверете резултата.

Типична картина от ежедневието: управлението на пакетите съобщава „PHP е актуализиран“, мониторингът не показва грешки, уебсайтът работи. Въпреки това старите worker процеси продължават да обслужват всяка заявка, защото никой не е рестартирал услугата. Отвън това състояние не се разпознава. Затова проверката на времената на стартиране на процесите спада към всяка актуализация.

## Кои услуги зареждат PHP?

| Режим на работа | Какво да се рестартира | Типична команда (имената се различават според дистрибуцията) |
|---|---|---|
| PHP-FPM | всяка FPM услуга, за всяка инсталирана версия | `systemctl restart php8.3-fpm` или `systemctl restart php-fpm` |
| Apache с mod_php | Apache | `systemctl restart apache2` или `systemctl restart httpd` |
| php-cgi | извикващия уеб сървър или FastCGI wrapper | според конфигурацията |
| LiteSpeed | LiteSpeed и процесите lsphp | през управлението на LiteSpeed или неговата услуга |
| FrankenPHP | услугата FrankenPHP или контейнера | `systemctl restart frankenphp` или контейнерът да се създаде наново |
| Docker, Kubernetes | контейнерите да се създадат наново от нов образ | вижте [Пачване на PHP в Docker контейнери](https://phpsos.de/bg/php2shell/docker-container-patchen/) |

При mod_php важи: актуализацията засяга самия Apache, защото PHP е във всеки процес на Apache. Защо този режим е особено деликатен, е описано на страницата [Защо mod_php носи най-висок риск](https://phpsos.de/bg/php2shell/mod-php-risiko/). За LiteSpeed подробности има на страницата [LiteSpeed и LSAPI](https://phpsos.de/bg/server/litespeed/).

## Рестартиране на PHP-FPM: командите

Първо намерете всички PHP услуги на сървъра. Plesk, cPanel и други интерфейси носят собствени PHP услуги със собствени имена; списъкът ги показва също.

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

След това рестартирайте всяка намерена PHP услуга, не само първата:

```bash
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm      # ако е инсталиран втори клон
sudo systemctl restart apache2         # при mod_php; семейство RHEL: httpd
```

Препоръчваме `restart` вместо `reload`. При reload главният процес остава; той е предназначен за промени в конфигурацията. След актуализация за сигурност искате да сте сигурни, че всеки процес е нов.

> **Важно:**
> Ако сте задали допълнително временни мерки като `session.upload_progress.enabled=0` или твърди ограничения на паметта, те също действат едва след рестартирането. Едно рестартиране урежда и двете наведнъж.

## Проверка, че не работи стар worker

Сравнете времето на стартиране на процесите с момента на актуализацията. Всички команди са само за четене.

```bash
ps -o pid,lstart,cmd -C php-fpm8.3     # unter RHEL: -C php-fpm
systemctl status php8.3-fpm            # редът „Active: … since …“
needrestart -r l                       # Debian/Ubuntu, ако е инсталиран
```

Ако един процес е по-стар от актуализацията, той не е бил обхванат. Чести причини са забравен втори PHP клон, самостоятелна услуга на пул от хостинг панел или контейнер, който е само рестартиран, вместо да е създаден от новия образ. Дали работи правилната версия, показва страницата [Как да проверите правилно PHP версията и състоянието на пача](https://phpsos.de/bg/php2shell/php-version-pruefen/).

## Документиране на рестартирането

Запишете за всеки сървър момента на актуализацията и на рестартирането. Този момент разграничава времето, в което сървърът е бил уязвим, от времето след това. За по-късна проверка на следите, за застрахователи и за възможно уведомяване по ОРЗД това е най-важната опорна точка. Съхранявайте освен това сървърните логове от 20 октомври нататък, както препоръчва специализираната преса.

На сървъри с много уебсайтове си струва кратка таблица: сървър, услуга, PHP версия, версия на пакета, момент на рестартирането и лицето, което е рестартирало. Така пропуските в покритието се забелязват бързо, например пропуснат пул или тестова система, която никой не е имал в списъка.

## Как помага PHP SOS конкретно?

В рамките на [услугата за пач на PHP](https://phpsos.de/bg/leistungen/php-patch-service/) поемаме актуализацията и рестартирането като свързан ход:

- **Установяване на услугите:** Намираме всички процеси, които зареждат PHP, също и от хостинг панели и контейнери.
- **Контролирано рестартиране,** по договорка с Вас в подходящ момент и с оглед на текущите поръчки или формуляри.
- **Последваща проверка,** че нито един процес не е по-стар от актуализацията и уебсайтът отговаря нормално.
- **Протоколиране:** версии, състояния на пакетите и времена на рестартиране за всеки сървър.


## Често задавани въпроси

**Достатъчно ли е systemctl reload вместо restart?**  
За PHP2Shell препоръчваме restart. Reload обикновено рестартира worker процесите, но главният процес може да продължи да работи. С restart се уверявате, че не остава процес със стар код. Срещу краткото прекъсване стои ясно доказателство.

**Трябва ли след PHP актуализацията да рестартирам целия сървър?**  
По правило не. Достатъчно е да се рестартират всички услуги, които зареждат PHP: PHP-FPM, Apache при mod_php, LiteSpeed, FrankenPHP или засегнатите контейнери. Рестартирането на целия сървър е простият вариант, ако не сте сигурни кои услуги ползват PHP.

**Рестартира ли моят хостинг доставчик PHP автоматично след актуализацията?**  
Това зависи от доставчика. Попитайте конкретно дали след пача всички PHP процеси са рестартирани и поискайте потвърждение писмено.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)