Lühidalt: Pärast PHP uuendust peate PHP-FPM-i ja kõik teised PHP-d laadivad teenused uuesti käivitama. Uued failid kõvakettal ei piisa, kuni vanad PHP protsessid mälus töötavad. Alles pärast taaskäivitust töötab server parandatud koodiga PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 või teie pakkuja tagasiportimisega.
Miks peate PHP-FPM-i uuesti käivitama
Paketiuuendus asendab failid kõvakettal. Protsessid, mis juba töötavad, on aga vana programmikoodi juba mällu laadinud ja töötavad sellega edasi. PHP-FPM, Apache mod_php-ga või LiteSpeed hoiavad oma tööprotsesse sageli päevi elus.
PHP2Shelli puhul on see eriti oluline. Turvaauk CVE-2026-109619 seisneb just seisundis, mis jääb päringute vahele samas tööprotsessis alles. Vana koodiga tööprotsess jääb haavatavaks, olenemata sellest, milline versioon kettal on. php.net-i järgi tuleb seetõttu kõik tööprotsessid ja protsessid uuesti käivitada.
Mõned paketihaldurid käivitavad teenused uuenduse ajal automaatselt uuesti, teised mitte. Ärge sellele lootke, vaid kontrollige tulemust.
Tüüpiline pilt igapäevast: paketihaldus teatab „PHP uuendatud“, seire ei näita vigu, veebisait töötab. Sellest hoolimata teenindavad vanad tööprotsessid edasi iga päringut, sest keegi ei ole teenust uuesti käivitanud. Väljastpoolt seda seisundit ei ära tunne. Seetõttu kuulub protsesside algusaegade kontroll iga uuenduse juurde.
Millised teenused PHP-d laadivad?
| Töörežiim | Mida uuesti käivitada | Tüüpiline käsk (nimed sõltuvad distributsioonist) |
|---|---|---|
| PHP-FPM | iga FPM-i teenus, iga paigaldatud versiooni kohta | systemctl restart php8.3-fpm või systemctl restart php-fpm |
| Apache koos mod_php-ga | Apache | systemctl restart apache2 või systemctl restart httpd |
| php-cgi | kutsuv veebiserver või FastCGI-wrapper | olenevalt seadistusest |
| LiteSpeed | LiteSpeed ja lsphp protsessid | LiteSpeedi halduse või selle teenuse kaudu |
| FrankenPHP | FrankenPHP teenus või konteiner | systemctl restart frankenphp või konteiner uuesti luua |
| Docker, Kubernetes | konteinerid uuesti luua uuest tõmmisest | vt PHP paikamine Dockeri konteinerites |
mod_php puhul kehtib: uuendus puudutab Apache'i ennast, sest PHP asub igas Apache'i protsessis. Miks see töörežiim on eriti tundlik, on kirjas lehel Miks mod_php kannab suurimat riski. LiteSpeedi kohta leiate üksikasju lehelt LiteSpeed ja LSAPI.
PHP-FPM taaskäivitus: käsud
Kõigepealt leidke serveris kõik PHP teenused. Plesk, cPanel ja teised liidesed toovad kaasa oma PHP teenused oma nimedega; loend näitab neid kaasa.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
Seejärel käivitage iga leitud PHP teenus uuesti, mitte ainult esimene:
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm # kui teine haru on paigaldatud
sudo systemctl restart apache2 # mod_php puhul; RHEL-i perekond: httpd
Soovitame restart mitte reload. Reloadi korral jääb põhiprotsess alles; see on mõeldud seadistusmuudatusteks. Pärast turvauuendust tahate olla kindel, et iga protsess on uus.
Kui olete lisaks seadnud ajutised meetmed nagu session.upload_progress.enabled=0 või kindlad mälupiirid, rakenduvad needki alles pärast taaskäivitust. Taaskäivitus teeb mõlemad ühe sammuga.
Kontroll, et ükski vana tööprotsess enam ei tööta
Võrrelge protsesside algusaega uuenduse ajahetkega. Kõik käsud on puhtalt lugevad.
ps -o pid,lstart,cmd -C php-fpm8.3 # RHEL-is: -C php-fpm
systemctl status php8.3-fpm # rida „Active: … since …“
needrestart -r l # Debian/Ubuntu, kui paigaldatud
Kui protsess on uuendusest vanem, ei ole see hõlmatud. Sagedased põhjused on unustatud teine PHP haru, majutuspaneeli oma pooli teenus või konteiner, mis käivitati ainult uuesti, selle asemel et luua uuest tõmmisest. Kas õige versioon töötab, näitab lehekülg PHP versiooni ja paigatud seisu õige kontroll.
Taaskäivituse dokumenteerimine
Märkige iga serveri kohta üles uuenduse ja taaskäivituse ajahetk. See hetk eraldab aja, mil server oli haavatav, ajast pärast seda. Hilisema jälgede kontrolli, kindlustajate ja võimaliku IKÜM-i alusel teavituse jaoks on see kõige olulisem võrdluspunkt. Hoidke lisaks serveri logisid alles alates 20. oktoobrist, nagu erialaajakirjandus soovitab.
Paljude veebisaitidega serverite puhul tasub koostada lühike tabel: server, teenus, PHP versioon, paketi versioon, taaskäivituse ajahetk ja isik, kes taaskäivitas. Nii tulevad katte lüngad kiiresti ilmsiks, näiteks unustatud pool või testsüsteem, mida keegi nimekirjas ei hoidnud.
Kuidas PHP SOS konkreetselt aitab?
PHP paikamisteenuse raames võtame uuenduse ja taaskäivituse enda peale ühtse käiguna:
- Teenuste kindlakstegemine: Leiame kõik protsessid, mis PHP-d laadivad, ka majutuspaneelidest ja konteineritest.
- Kontrollitud taaskäivitus, teiega kokkuleppel sobival ajal ja pidades silmas käimasolevaid tellimusi või vorme.
- Järelkontroll, et ükski protsess pole uuendusest vanem ja veebisait vastab normaalselt.
- Protokollimine: versioonid, paketi seisud ja taaskäivituse ajad iga serveri kohta.
Korduma kippuvad küsimused
Kas systemctl reload piisab restart'i asemel?
PHP2Shelli puhul soovitame restart'i. Reload käivitab tööprotsessid küll tavaliselt uuesti, kuid põhiprotsess võib edasi töötada. Restart'iga olete kindel, et ükski protsess vana koodiga alles ei jää. Lühikesele katkestusele vastab selge tõend.
Kas pean pärast PHP uuendust kogu serveri uuesti käivitama?
Üldjuhul mitte. Piisab kõigi PHP-d laadivate teenuste uuesti käivitamisest: PHP-FPM, Apache mod_php puhul, LiteSpeed, FrankenPHP või mõjutatud konteinerid. Kogu serveri taaskäivitus on lihtne variant, kui te ei ole kindel, millised teenused PHP-d kasutavad.
Kas minu veebimajutaja käivitab PHP pärast uuendust automaatselt uuesti?
See sõltub pakkujast. Küsige konkreetselt, kas pärast paika on kõik PHP protsessid uuesti käivitatud, ja laske see endale kirjalikult kinnitada.