Īsi: pēc PHP atjauninājuma jāpārstartē PHP-FPM un visi pārējie pakalpojumi, kas ielādē PHP. Ar jauniem failiem diskā nepietiek, kamēr atmiņā darbojas veci PHP procesi. Tikai pēc pārstartēšanas serveris strādā ar labotu kodu no PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 vai sniedzēja backport.
Kāpēc PHP-FPM jāpārstartē
Pakotnes atjauninājums aizstāj failus diskā. Bet procesi, kas jau darbojas, vecais programmas kods jau ir ielādēts atmiņā, un tie ar to strādā tālāk. PHP-FPM, Apache ar mod_php vai LiteSpeed savus darbprocesus bieži uztur dzīvus vairākas dienas.
PHP2Shell gadījumā tas ir īpaši svarīgi. Ievainojamība CVE-2026-109619 ir saistīta tieši ar stāvokli, kas starp pieprasījumiem paliek tajā pašā darbprocesā. Darbprocess ar veco kodu paliek ievainojams neatkarīgi no tā, kura versija atrodas diskā. Saskaņā ar php.net tāpēc jāpārstartē visi darbprocesi un procesi.
Daži pakotņu pārvaldnieki pakalpojumus atjaunināšanas laikā pārstartē automātiski, citi ne. Nepaļaujieties uz to, bet pārbaudiet rezultātu.
Tipisks attēls ikdienā: pakotņu pārvaldība ziņo „PHP atjaunināts“, monitorings nerāda kļūdas, vietne darbojas. Tomēr vecie darbprocesi turpina apkalpot katru pieprasījumu, jo neviens nav pakalpojumu pārstartējis. No ārpuses šo stāvokli nevar atpazīt. Tāpēc procesu startēšanas laiku pārbaude pieder pie katra atjauninājuma.
Kuri pakalpojumi ielādē PHP?
| Darbības režīms | Ko pārstartēt | Tipiska komanda (nosaukumi atkarībā no distributīva atšķiras) |
|---|---|---|
| PHP-FPM | katru FPM pakalpojumu, katrai instalētajai versijai | systemctl restart php8.3-fpm vai systemctl restart php-fpm |
| Apache ar mod_php | Apache | systemctl restart apache2 vai systemctl restart httpd |
| php-cgi | izsaucošo tīmekļa serveri vai FastCGI apvalku | atkarībā no konfigurācijas |
| LiteSpeed | LiteSpeed un lsphp procesus | ar LiteSpeed pārvaldību vai tā pakalpojumu |
| FrankenPHP | FrankenPHP pakalpojumu vai konteineru | systemctl restart frankenphp vai konteineru izveidot no jauna |
| Docker, Kubernetes | konteinerus izveidot no jauna no jauna attēla | skatiet PHP ielāpošana Docker konteineros |
Mod_php gadījumā: atjauninājums skar pašu Apache, jo PHP atrodas katrā Apache procesā. Kāpēc šis darbības režīms ir īpaši jutīgs, rakstīts sadaļā Kāpēc mod_php rada augstāko risku. Par LiteSpeed sīkāk lasiet lapā LiteSpeed un LSAPI.
PHP-FPM pārstartēšana: komandas
Vispirms atrodiet visus PHP pakalpojumus serverī. Plesk, cPanel un citas saskarnes nāk ar savām PHP pakalpojumiem ar saviem nosaukumiem; saraksts tos parāda līdzi.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
Pēc tam pārstartējiet katru atrasto PHP pakalpojumu, ne tikai pirmo:
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm # ja ir instalēts otrs atzars
sudo systemctl restart apache2 # mod_php gadījumā; RHEL saime: httpd
Mēs iesakām restart, nevis reload. Reload gadījumā galvenais process saglabājas; tas ir paredzēts konfigurācijas izmaiņām. Pēc drošības atjauninājuma vēlaties būt droši, ka katrs process ir jauns.
Ja papildus esat iestatījuši pagaidu pasākumus, piemēram, session.upload_progress.enabled=0 vai stingras atmiņas robežas, arī tie stājas spēkā tikai pēc pārstartēšanas. Pārstartēšana paveic abus vienā solī.
Pārbaudīt, ka vecs darbprocess vairs nedarbojas
Salīdziniet procesu startēšanas laiku ar atjauninājuma laiku. Visas komandas ir tikai lasošas.
ps -o pid,lstart,cmd -C php-fpm8.3 # RHEL sistēmās: -C php-fpm
systemctl status php8.3-fpm # rinda „Active: … since …“
needrestart -r l # Debian/Ubuntu, ja instalēts
Ja process ir vecāks par atjauninājumu, tas nav ticis aptverts. Biežākie iemesli ir aizmirsts otrs PHP atzars, atsevišķs pūla pakalpojums no hostinga paneļa vai konteiners, kas tikai pārstartēts, nevis izveidots no jaunā attēla. Vai darbojas pareizā versija, parāda lapa PHP versijas un ielāpa stāvokļa pareiza pārbaude.
Dokumentēt pārstartēšanu
Katram serverim pierakstiet atjauninājuma un pārstartēšanas laiku. Šis brīdis nošķir laiku, kad serveris bija ievainojams, no laika pēc tam. Vēlākai pēdu pārbaudei, apdrošinātājiem un iespējamam ziņojumam saskaņā ar VDAR tas ir svarīgākais atskaites punkts. Saglabājiet arī servera žurnālus no 20. oktobra, kā to iesaka speciālistu prese.
Serveros ar daudzām vietnēm noder īsa tabula: serveris, pakalpojums, PHP versija, pakotnes versija, pārstartēšanas laiks un persona, kas pārstartēja. Tā nepilnības aptvērumā ātri kļūst redzamas, piemēram, pūls, kas ticis palaists garām, vai testa sistēma, par kuru neviens nezināja.
Kā PHP SOS palīdz konkrēti?
PHP ielāpu pakalpojuma ietvaros mēs atjauninājumu un pārstartēšanu uzņemamies kā vienotu norisi:
- Noskaidrot pakalpojumus: Mēs atrodam visus procesus, kas ielādē PHP, arī no hostinga paneļiem un konteineriem.
- Pārstartēt kontrolēti, saskaņā ar jums piemērotā laikā un ņemot vērā notiekošos pasūtījumus vai veidlapas.
- Pārbaudīt, ka neviens process nav vecāks par atjauninājumu un vietne atbild normāli.
- Protokolēt: versijas, pakotņu stāvokli un pārstartēšanas laikus katram serverim.
Biežāk uzdotie jautājumi
Vai pietiek ar systemctl reload, nevis restart?
PHP2Shell gadījumā iesakām restart. Reload darbprocesus parasti tiešām pārstartē, taču galvenais process var turpināt darboties. Ar restart pārliecinieties, ka nepaliek neviens process ar veco kodu. Īsajam pārtraukumam pretī stāv skaidrs pierādījums.
Vai pēc PHP atjauninājuma man jāpārstartē viss serveris?
Parasti nē. Pietiek pārstartēt visus pakalpojumus, kas ielādē PHP: PHP-FPM, Apache mod_php gadījumā, LiteSpeed, FrankenPHP vai skartos konteinerus. Visa servera pārstartēšana ir vienkāršais variants, ja neesat droši, kuri pakalpojumi izmanto PHP.
Vai mans hostinga sniedzējs pēc atjauninājuma PHP pārstartē automātiski?
Tas ir atkarīgs no sniedzēja. Jautājiet konkrēti, vai pēc ielāpa visi PHP procesi ir pārstartēti, un lūdziet to apstiprināt rakstiski.