Накратко: След 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 е свързана именно със състояние, което остава между заявките в същия 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 контейнери |
При mod_php важи: актуализацията засяга самия Apache, защото PHP е във всеки процес на Apache. Защо този режим е особено деликатен, е описано на страницата Защо mod_php носи най-висок риск. За LiteSpeed подробности има на страницата LiteSpeed и LSAPI.
Рестартиране на PHP-FPM: командите
Първо намерете всички PHP услуги на сървъра. Plesk, cPanel и други интерфейси носят собствени PHP услуги със собствени имена; списъкът ги показва също.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
След това рестартирайте всяка намерена PHP услуга, не само първата:
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
Сравнете времето на стартиране на процесите с момента на актуализацията. Всички команди са само за четене.
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 версията и състоянието на пача.
Документиране на рестартирането
Запишете за всеки сървър момента на актуализацията и на рестартирането. Този момент разграничава времето, в което сървърът е бил уязвим, от времето след това. За по-късна проверка на следите, за застрахователи и за възможно уведомяване по ОРЗД това е най-важната опорна точка. Съхранявайте освен това сървърните логове от 20 октомври нататък, както препоръчва специализираната преса.
На сървъри с много уебсайтове си струва кратка таблица: сървър, услуга, PHP версия, версия на пакета, момент на рестартирането и лицето, което е рестартирало. Така пропуските в покритието се забелязват бързо, например пропуснат пул или тестова система, която никой не е имал в списъка.
Как помага PHP SOS конкретно?
В рамките на услугата за пач на PHP поемаме актуализацията и рестартирането като свързан ход:
- Установяване на услугите: Намираме всички процеси, които зареждат PHP, също и от хостинг панели и контейнери.
- Контролирано рестартиране, по договорка с Вас в подходящ момент и с оглед на текущите поръчки или формуляри.
- Последваща проверка, че нито един процес не е по-стар от актуализацията и уебсайтът отговаря нормално.
- Протоколиране: версии, състояния на пакетите и времена на рестартиране за всеки сървър.
Често задавани въпроси
Достатъчно ли е systemctl reload вместо restart?
За PHP2Shell препоръчваме restart. Reload обикновено рестартира worker процесите, но главният процес може да продължи да работи. С restart се уверявате, че не остава процес със стар код. Срещу краткото прекъсване стои ясно доказателство.
Трябва ли след PHP актуализацията да рестартирам целия сървър?
По правило не. Достатъчно е да се рестартират всички услуги, които зареждат PHP: PHP-FPM, Apache при mod_php, LiteSpeed, FrankenPHP или засегнатите контейнери. Рестартирането на целия сървър е простият вариант, ако не сте сигурни кои услуги ползват PHP.
Рестартира ли моят хостинг доставчик PHP автоматично след актуализацията?
Това зависи от доставчика. Попитайте конкретно дали след пача всички PHP процеси са рестартирани и поискайте потвърждение писмено.