Lyhyesti: PHP-päivityksen jälkeen teidän on käynnistettävä uudelleen PHP-FPM ja kaikki muut palvelut, jotka lataavat PHP:n. Levyllä olevat uudet tiedostot eivät riitä, kunhan vanhat PHP-prosessit toimivat muistissa. Vasta uudelleenkäynnistyksen jälkeen palvelin toimii versioiden PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 tai palveluntarjoajanne backportin korjatulla koodilla.
Miksi PHP-FPM on käynnistettävä uudelleen
Pakettipäivitys korvaa levyllä olevat tiedostot. Jo käynnissä olevat prosessit ovat kuitenkin ladanneet vanhan ohjelmakoodin muistiin ja jatkavat sillä. PHP-FPM, Apache mod_php:n kanssa tai LiteSpeed pitävät workerinsa usein käynnissä päiväkausia.
PHP2Shellin osalta tämä on erityisen tärkeää. Haavoittuvuus CVE-2026-109619 liittyy juuri tilaan, joka säilyy pyyntöjen välillä samassa workerissa. Worker vanhalla koodilla pysyy haavoittuvana riippumatta siitä, mikä versio on levyllä. php.netin mukaan kaikki workerit ja prosessit on siksi käynnistettävä uudelleen.
Jotkin paketinhallintajärjestelmät käynnistävät palvelut päivityksen yhteydessä automaattisesti uudelleen, toiset eivät. Älkää luottako siihen vaan tarkistakaa tulos.
Tyypillinen arkikuva: paketinhallinta ilmoittaa „PHP päivitetty“, valvonta ei näytä virheitä, verkkosivusto toimii. Silti vanhat workerit palvelevat edelleen jokaista pyyntöä, koska kukaan ei ole käynnistänyt palvelua uudelleen. Ulkopuolelta tätä tilaa ei voi tunnistaa. Siksi prosessien käynnistysaikojen tarkistus kuuluu jokaiseen päivitykseen.
Mitkä palvelut lataavat PHP:n?
| Ajotapa | Mitä käynnistetään uudelleen | Tyypillinen komento (nimet vaihtelevat jakelun mukaan) |
|---|---|---|
| PHP-FPM | jokainen FPM-palvelu, asennettua versiota kohti | systemctl restart php8.3-fpm tai systemctl restart php-fpm |
| Apache mod_php:n kanssa | Apache | systemctl restart apache2 tai systemctl restart httpd |
| php-cgi | kutsuva verkkopalvelin tai FastCGI-wrapper | ympäristön mukaan |
| LiteSpeed | LiteSpeed ja lsphp-prosessit | LiteSpeedin hallinnan tai sen palvelun kautta |
| FrankenPHP | FrankenPHP-palvelu tai kontti | systemctl restart frankenphp tai kontin uudelleenluonti |
| Docker, Kubernetes | konttien uudelleenluonti uudesta imagesta | katso PHP:n korjaus Docker-konteissa |
mod_php:ssä pätee: päivitys koskee Apachea itseään, koska PHP on jokaisessa Apache-prosessissa. Miksi tämä ajotapa on erityisen arka, kerrotaan sivulla Miksi mod_php kantaa suurimman riskin. LiteSpeedin yksityiskohdat löydätte sivulta LiteSpeed ja LSAPI.
PHP-FPM:n uudelleenkäynnistys: komennot
Etsikää ensin kaikki palvelimen PHP-palvelut. Plesk, cPanel ja muut käyttöliittymät tuovat mukanaan omia PHP-palvelujaan omin nimin; luettelo näyttää ne mukana.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
Sen jälkeen käynnistäkää jokainen löydetty PHP-palvelu uudelleen, älkää vain ensimmäistä:
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm # jos toinen haara on asennettu
sudo systemctl restart apache2 # mod_php:n kanssa; RHEL-perhe: httpd
Suosittelemme restart eikä reload. Reloadissa pääprosessi säilyy; se on tarkoitettu konfiguraatiomuutoksiin. Tietoturvapäivityksen jälkeen haluatte olla varmoja, että jokainen prosessi on uusi.
Jos olette asettaneet lisäksi väliaikaisia toimenpiteitä, kuten session.upload_progress.enabled=0 tai kiinteitä muistirajoja, nekin tehoavat vasta uudelleenkäynnistyksen jälkeen. Uudelleenkäynnistys hoitaa molemmat yhdellä kertaa.
Tarkistus, ettei vanhoja workereita ole enää käynnissä
Vertailkaa prosessien käynnistysaikaa päivityksen ajankohtaan. Kaikki komennot ovat pelkästään lukevia.
ps -o pid,lstart,cmd -C php-fpm8.3 # RHEL:ssä: -C php-fpm
systemctl status php8.3-fpm # rivi „Active: … since …“
needrestart -r l # Debian/Ubuntu, jos asennettu
Jos prosessi on päivitystä vanhempi, sitä ei ole tavoitettu. Yleisiä syitä ovat unohtunut toinen PHP-haara, hosting-paneelin oma pooli-palvelu tai kontti, joka on vain käynnistetty uudelleen sen sijaan että se olisi luotu uudesta imagesta. Toimiiko oikea versio, näyttää sivu PHP-version ja korjaustilan tarkistaminen oikein.
Uudelleenkäynnistyksen dokumentointi
Kirjatkaa jokaisesta palvelimesta päivityksen ja uudelleenkäynnistyksen ajankohta. Tämä hetki erottaa ajan, jolloin palvelin oli haavoittuva, ajasta sen jälkeen. Myöhempää jälkien tarkistusta, vakuutusyhtiötä ja mahdollista GDPR:n mukaista ilmoitusta varten se on tärkein vertailukohta. Säilyttäkää lisäksi palvelinlokit 20. lokakuuta alkaen, kuten ammattilehdistö suosittelee.
Palvelimilla, joilla on paljon verkkosivustoja, kannattaa laatia lyhyt taulukko: palvelin, palvelu, PHP-versio, paketin versio, uudelleenkäynnistyksen ajankohta ja henkilö, joka käynnisti uudelleen. Näin aukot kattavuudessa huomataan nopeasti, esimerkiksi unohtunut pooli tai testijärjestelmä, jota kukaan ei ollut listalla.
Miten PHP SOS auttaa konkreettisesti?
PHP-korjauspalvelun puitteissa hoidamme päivityksen ja uudelleenkäynnistyksen yhtenäisenä kulkuna:
- Palveluiden selvitys: Löydämme kaikki prosessit, jotka lataavat PHP:n, myös hosting-paneeleista ja konteista.
- Hallittu uudelleenkäynnistys sovittuna sopivana ajankohtana ja käynnissä olevat tilaukset tai lomakkeet huomioiden.
- Jälkitarkistus: ettei mikään prosessi ole päivitystä vanhempi ja verkkosivusto vastaa normaalisti.
- Kirjaus: versiot, pakettitilat ja uudelleenkäynnistysajat palvelimittain.
Usein kysytyt kysymykset
Riittääkö systemctl reload restartin sijaan?
PHP2Shellin osalta suosittelemme restartia. Reload käynnistää workerit yleensä uudelleen, mutta pääprosessi voi jatkaa toimintaansa. Restartilla varmistatte, ettei yksikään prosessi jää vanhalla koodilla. Lyhyttä keskeytystä vastaa selvä todiste.
Pitääkö koko palvelin käynnistää uudelleen PHP-päivityksen jälkeen?
Yleensä ei. Riittää, että käynnistätte uudelleen kaikki palvelut, jotka lataavat PHP:n: PHP-FPM, Apache mod_php:n kanssa, LiteSpeed, FrankenPHP tai kyseiset kontit. Koko palvelimen uudelleenkäynnistys on yksinkertainen vaihtoehto, jos ette ole varma, mitkä palvelut käyttävät PHP:tä.
Käynnistääkö hosting-yritykseni PHP:n päivityksen jälkeen automaattisesti uudelleen?
Se riippuu palveluntarjoajasta. Kysykää täsmällisesti, onko kaikki PHP-prosessit käynnistetty uudelleen korjauksen jälkeen, ja pyytäkää vahvistus kirjallisesti.