# Dopo l'aggiornamento: riavviare PHP-FPM e tutti i worker

> Riavviare PHP-FPM dopo l'aggiornamento PHP2Shell: perché i nuovi file non bastano, quali servizi contano e come verificare che nessun vecchio worker giri.

Fonte: https://phpsos.de/it/php2shell/php-fpm-neustart/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**In breve:** dopo l'aggiornamento di PHP deve riavviare PHP-FPM e tutti gli altri servizi che caricano PHP. I nuovi file sul disco non bastano finché vecchi processi PHP girano in memoria. Solo dopo il riavvio il server lavora con il codice corretto di PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 o con il backport del Suo fornitore.

## Perché deve riavviare PHP-FPM

Un aggiornamento di pacchetto sostituisce i file sul disco. I processi già in esecuzione, però, hanno già caricato in memoria il vecchio codice del programma e continuano a lavorare con quello. PHP-FPM, Apache con mod_php o LiteSpeed tengono in vita i loro worker spesso per giorni.

Per PHP2Shell è particolarmente importante. La vulnerabilità [CVE-2026-109619](https://phpsos.de/it/php2shell/cve-2026-109619/) dipende proprio da uno stato che resta tra le richieste nello stesso worker. Un worker con il vecchio codice resta vulnerabile, qualunque versione si trovi sul disco. Secondo php.net, tutti i worker e i processi vanno quindi riavviati.

Alcuni gestori di pacchetti riavviano i servizi automaticamente durante l'aggiornamento, altri no. Non ci faccia affidamento, ma verifichi il risultato.

Un quadro tipico della quotidianità: la gestione dei pacchetti segnala «PHP aggiornato», il monitoraggio non mostra errori, il sito web funziona. Eppure i vecchi worker continuano a servire ogni richiesta, perché nessuno ha riavviato il servizio. Dall'esterno questo stato non si riconosce. Per questo la verifica degli orari di avvio dei processi fa parte di ogni aggiornamento.

## Quali servizi caricano PHP?

| Modalità di esecuzione | Che cosa riavviare | Comando tipico (nomi variabili a seconda della distribuzione) |
|---|---|---|
| PHP-FPM | ogni servizio FPM, per ogni versione installata | `systemctl restart php8.3-fpm` oppure `systemctl restart php-fpm` |
| Apache con mod_php | Apache | `systemctl restart apache2` oppure `systemctl restart httpd` |
| php-cgi | il web server chiamante o il wrapper FastCGI | a seconda della configurazione |
| LiteSpeed | LiteSpeed e i processi lsphp | tramite la gestione di LiteSpeed o il suo servizio |
| FrankenPHP | il servizio FrankenPHP o il container | `systemctl restart frankenphp` oppure ricreare il container |
| Docker, Kubernetes | ricreare i container da una nuova immagine | vedi [Applicare la patch a PHP nei container Docker](https://phpsos.de/it/php2shell/docker-container-patchen/) |

Con mod_php vale: l'aggiornamento riguarda Apache stesso, perché PHP è presente in ogni processo Apache. Perché questa modalità sia particolarmente delicata è spiegato alla pagina [Perché mod_php comporta il rischio più alto](https://phpsos.de/it/php2shell/mod-php-risiko/). Per LiteSpeed trova i dettagli alla pagina [LiteSpeed e LSAPI](https://phpsos.de/it/server/litespeed/).

## Riavviare PHP-FPM: i comandi

Per prima cosa trovi tutti i servizi PHP sul server. Plesk, cPanel e altre interfacce portano con sé servizi PHP propri con nomi propri; l'elenco li mostra.

```bash
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
```

Poi riavviare ogni servizio PHP trovato, non solo il primo:

```bash
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm      # se è installato un secondo ramo
sudo systemctl restart apache2         # con mod_php; famiglia RHEL: httpd
```

Raccomandiamo `restart` anziché `reload`. Con il reload il processo principale resta; è pensato per le modifiche di configurazione. Dopo un aggiornamento di sicurezza vuole essere certo che ogni processo sia nuovo.

> **Importante:**
> Se ha impostato anche misure provvisorie come `session.upload_progress.enabled=0` o limiti di memoria fissi, anch'esse hanno effetto solo dopo il riavvio. Un riavvio sbriga entrambe le cose in un solo passaggio.

## Verificare che nessun vecchio worker giri ancora

Confronti l'ora di avvio dei processi con il momento dell'aggiornamento. Tutti i comandi sono di sola lettura.

```bash
ps -o pid,lstart,cmd -C php-fpm8.3     # su RHEL: -C php-fpm
systemctl status php8.3-fpm            # riga «Active: … since …»
needrestart -r l                       # Debian/Ubuntu, se installato
```

Se un processo è più vecchio dell'aggiornamento, non è stato interessato. Cause frequenti sono un secondo ramo PHP dimenticato, un servizio di pool proprio proveniente da un pannello di hosting o un container che è stato solo riavviato invece di essere ricreato dalla nuova immagine. Quale versione giri lo mostra la pagina [Verificare correttamente versione e stato delle patch di PHP](https://phpsos.de/it/php2shell/php-version-pruefen/).

## Documentare il riavvio

Annoti per ogni server il momento dell'aggiornamento e del riavvio. Questo istante separa il periodo in cui il server era vulnerabile da quello successivo. Per una successiva verifica delle tracce, per gli assicuratori e per un'eventuale notifica ai sensi del GDPR è il riferimento più importante. Conservi inoltre i log del server a partire dal 20 ottobre, come consiglia la stampa specializzata.

Sui server con molti siti web vale la pena una breve tabella: server, servizio, versione di PHP, versione del pacchetto, momento del riavvio e persona che ha riavviato. In questo modo le lacune di copertura emergono in fretta, ad esempio un pool trascurato o un sistema di test che nessuno aveva in elenco.

## Come aiuta concretamente PHP SOS?

Nell'ambito del [servizio di patch PHP](https://phpsos.de/it/leistungen/php-patch-service/) ci occupiamo di aggiornamento e riavvio come processo unico:

- **Individuare i servizi:** troviamo tutti i processi che caricano PHP, anche quelli provenienti da pannelli di hosting e container.
- **Riavviare in modo controllato,** previo accordo con Lei a un momento adatto e con attenzione a ordini o moduli in corso.
- **Ricontrollare** che nessun processo sia più vecchio dell'aggiornamento e che il sito web risponda normalmente.
- **Verbalizzare:** versioni, stati dei pacchetti e orari di riavvio per ogni server.


## Domande frequenti

**Basta systemctl reload invece di restart?**  
Per PHP2Shell raccomandiamo restart. Un reload di solito riavvia i worker, ma il processo principale può continuare a girare. Con restart si ha la certezza che non resti alcun processo con il vecchio codice. All'interruzione breve si contrappone una prova chiara.

**Dopo l'aggiornamento di PHP devo riavviare l'intero server?**  
Di norma no. Basta riavviare tutti i servizi che caricano PHP: PHP-FPM, Apache con mod_php, LiteSpeed, FrankenPHP o i container interessati. Riavviare l'intero server è la variante semplice se non è sicuro di quali servizi usino PHP.

**Il mio hoster riavvia PHP automaticamente dopo l'aggiornamento?**  
Dipende dal fornitore. Chieda in modo concreto se dopo la patch tutti i processi PHP siano stati riavviati e se lo faccia confermare per iscritto.

## Fonti

- [php.net: bollettini di sicurezza](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)