Trumpai: Po PHP atnaujinimo reikia paleisti iš naujo PHP-FPM ir visas kitas tarnybas, įkeliančias PHP. Vien naujų failų diske nepakanka, kol atmintyje veikia seni PHP procesai. Tik po paleidimo iš naujo serveris dirba su pataisytu PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 kodu arba jūsų teikėjo atgaliniu perkėlimu (backport).
Kodėl PHP-FPM reikia paleisti iš naujo
Paketų atnaujinimas pakeičia failus diske. Tačiau jau veikiantys procesai senąjį programos kodą į atmintį jau yra įkėlę ir su juo dirba toliau. PHP-FPM, Apache su mod_php ar LiteSpeed savo darbinius procesus (worker) dažnai palaiko gyvus dienų dienas.
PHP2Shell tai ypač svarbu. Spraga CVE-2026-109619 susijusi būtent su būsena, kuri tarp užklausų išlieka tame pačiame darbiniame procese. Darbinis procesas su senu kodu lieka pažeidžiamas, kad ir kokia versija gulėtų diske. Pasak php.net, todėl reikia paleisti iš naujo visus darbinius procesus ir procesus.
Kai kurie paketų valdytojai tarnybas atnaujinimo metu paleidžia iš naujo automatiškai, kiti ne. Nepasikliaukite tuo, o patikrinkite rezultatą.
Tipiškas kasdienybės vaizdas: paketų valdymas praneša „PHP atnaujintas“, stebėsena klaidų nerodo, svetainė veikia. Vis dėlto seni darbiniai procesai toliau aptarnauja kiekvieną užklausą, nes niekas tarnybos nepaleido iš naujo. Iš išorės šios būsenos neatpažinti. Todėl proceso paleidimo laikų patikra priklauso kiekvienam atnaujinimui.
Kurios tarnybos įkelia PHP?
| Veikimo režimas | Ką paleisti iš naujo | Tipinė komanda (pavadinimai skiriasi pagal distribuciją) |
|---|---|---|
| PHP-FPM | kiekvieną FPM tarnybą, pagal įdiegtą versiją | systemctl restart php8.3-fpm arba systemctl restart php-fpm |
| Apache su mod_php | Apache | systemctl restart apache2 arba systemctl restart httpd |
| php-cgi | kviečiantį žiniatinklio serverį arba FastCGI apvalkalą | pagal sąranką |
| LiteSpeed | LiteSpeed ir lsphp procesus | per LiteSpeed valdymą arba jo tarnybą |
| FrankenPHP | FrankenPHP tarnybą arba konteinerį | systemctl restart frankenphp arba konteinerį sukurti iš naujo |
| Docker, Kubernetes | konteinerius sukurti iš naujo iš naujo atvaizdo | žr. PHP pataisymas Docker konteineriuose |
Esant mod_php: atnaujinimas paliečia patį Apache, nes PHP yra kiekviename Apache procese. Kodėl šis veikimo režimas ypač jautrus, aprašyta puslapyje Kodėl mod_php kelia didžiausią riziką. LiteSpeed detales rasite puslapyje LiteSpeed ir LSAPI.
PHP-FPM paleidimas iš naujo: komandos
Pirmiausia suraskite visas serverio PHP tarnybas. Plesk, cPanel ir kitos sąsajos turi savas PHP tarnybas su savais pavadinimais; sąrašas jas parodo.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
Po to kiekvieną rastą PHP tarnybą paleiskite iš naujo, ne tik pirmąją:
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm # jei įdiegta antra šaka
sudo systemctl restart apache2 # esant mod_php; RHEL šeima: httpd
Rekomenduojame restart, o ne reload. Esant reload, pagrindinis procesas lieka; tai skirta konfigūracijos pakeitimams. Po saugumo atnaujinimo norite būti tikri, kad kiekvienas procesas naujas.
Jei papildomai nustatėte pereinamąsias priemones, tokias kaip session.upload_progress.enabled=0 ar fiksuotos atminties ribos, jos taip pat suveikia tik po paleidimo iš naujo. Paleidimas iš naujo atlieka abu vienu žingsniu.
Patikrinti, kad nebeveikia senas darbinis procesas
Palyginkite procesų paleidimo laiką su atnaujinimo laiku. Visos komandos tik skaito.
ps -o pid,lstart,cmd -C php-fpm8.3 # RHEL sistemose: -C php-fpm
systemctl status php8.3-fpm # eilutė „Active: … since …“
needrestart -r l # Debian/Ubuntu, jei įdiegta
Jei procesas senesnis už atnaujinimą, jis nebuvo aprėptas. Dažnos priežastys: užmiršta antra PHP šaka, atskira baseino tarnyba iš talpinimo skydelio arba konteineris, kuris tik paleistas iš naujo, o ne sukurtas iš naujo atvaizdo. Ar veikia teisinga versija, parodo puslapis Kaip teisingai patikrinti PHP versiją ir pataisų būseną.
Paleidimą iš naujo dokumentuoti
Kiekvienam serveriui užsirašykite atnaujinimo ir paleidimo iš naujo laiką. Šis momentas atskiria laiką, kai serveris buvo pažeidžiamas, nuo laiko po to. Vėlesnei pėdsakų patikrai, draudikui ir galimam pranešimui pagal BDAR tai yra svarbiausias atskaitos taškas. Be to, saugokite serverio žurnalus nuo spalio 20 d., kaip rekomenduoja specializuota spauda.
Serveriuose su daug svetainių verta turėti trumpą lentelę: serveris, tarnyba, PHP versija, paketo versija, paleidimo iš naujo laikas ir asmuo, kuris paleido iš naujo. Taip greitai išryškėja aprėpties spragos, pavyzdžiui, praleistas baseinas ar bandomoji sistema, kurios niekas neturėjo sąraše.
Kaip PHP SOS padeda konkrečiai?
Vykdydami PHP pataisų paslaugą atnaujinimą ir paleidimą iš naujo perimame kaip vientisą eigą:
- Nustatyti tarnybas: Randame visus procesus, įkeliančius PHP, taip pat iš talpinimo skydelių ir konteinerių.
- Paleisti iš naujo kontroliuojamai, suderintu su jumis tinkamu laiku ir atsižvelgdami į vykstančius užsakymus ar formas.
- Patikrinti, kad joks procesas nėra senesnis už atnaujinimą ir svetainė atsako normaliai.
- Protokoluoti: versijos, paketų būsenos ir paleidimo iš naujo laikai kiekvienam serveriui.
Dažni klausimai
Ar užtenka systemctl reload vietoj restart?
PHP2Shell atveju rekomenduojame restart. Reload dažniausiai darbinius procesus paleidžia iš naujo, bet pagrindinis procesas gali toliau veikti. Su restart užtikrinate, kad neliks proceso su senu kodu. Trumpam pertrūkiui priešpastatomas aiškus įrodymas.
Ar po PHP atnaujinimo turiu paleisti iš naujo visą serverį?
Paprastai ne. Pakanka paleisti iš naujo visas tarnybas, įkeliančias PHP: PHP-FPM, Apache esant mod_php, LiteSpeed, FrankenPHP ar paveiktus konteinerius. Viso serverio paleidimas iš naujo yra paprasta galimybė, kai nesate tikri, kurios tarnybos naudoja PHP.
Ar mano talpintojas po atnaujinimo PHP paleidžia iš naujo automatiškai?
Tai priklauso nuo teikėjo. Paklauskite konkrečiai, ar po pataisos paleisti iš naujo visi PHP procesai, ir paprašykite tai patvirtinti raštu.