OPcache codice PHP vecchio può comparire quando il bytecode compilato non viene invalidato dopo una modifica. Il comportamento dipende da validate_timestamps, revalidate_freq, processi PHP e dall’eventuale file cache.
Questa guida approfondisce OPcache codice PHP vecchio con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.
Che cosa significa
`opcache_reset()` azzera la cache opcode in memoria del processo che esegue la funzione e gli script vengono ricompilati alle richieste successive. La documentazione PHP precisa che non elimina la file cache.
Un reset globale può causare una breve ricompilazione di molti script e aumentare il carico. Prima è preferibile invalidare il file interessato o usare il meccanismo di restart previsto dal server.
Come riconoscere il problema
- Il file sul disco è nuovo ma il sito mostra il comportamento precedente.
- Solo alcuni processi servono il vecchio codice.
- Il problema appare dopo deploy atomico.
- Riavviando PHP la modifica diventa visibile.
- La CLI vede il nuovo file ma il web no.
Cause più frequenti
1. validate_timestamps disattivato
OPcache non controlla automaticamente le modifiche. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
2. revalidate_freq elevato
Il controllo avviene dopo un intervallo. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
3. Processi multipli
Pool differenti possiedono cache separate. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
4. File cache
Il bytecode persistente può avere regole proprie. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
5. Deploy con inode o symlink
Il processo mantiene riferimenti al vecchio percorso. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
6. Altra cache
Page cache, CDN o browser possono sembrare OPcache. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
Diagnosi passo per passo
- Verifica il contenuto dal server. Confronta hash e timestamp del file. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Escludi page cache. Controlla una risposta dinamica o aggiungi un marcatore temporaneo sicuro. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Leggi configurazione OPcache. Controlla validate_timestamps, revalidate_freq e file_cache. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Confronta CLI e web. Possono usare processi e ini differenti. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Identifica il pool PHP. Verifica versione e handler del dominio. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Invalida un singolo file. Quando disponibile usa `opcache_invalidate` nel contesto corretto. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Monitora il carico. Prima di un reset globale valuta il traffico. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
Metodo sicuro di diagnosi
Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.
Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.
Procedura di risoluzione
- Usa il restart previsto da LiteSpeed. Il marker di riavvio ricarica i processi PHP in modo controllato. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Invalida il file modificato. Riduce l’impatto rispetto al reset completo. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Esegui opcache_reset nel contesto web corretto. Non assumere che la CLI resetti il pool web. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Configura timestamp coerenti. Scegli valori adatti al metodo di deploy. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi il deploy atomico. Prevedi invalidazione o restart dopo il cambio release. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Pulisci le altre cache. LiteSpeed e CDN possono servire HTML precedente. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Rimuovi script di reset temporanei. Non lasciare endpoint pubblici che eseguono opcache_reset. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
Verifica della stabilità dopo l’intervento
Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.
Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.
Controlli finali
- Il codice nuovo viene eseguito.
- Tutti i processi rispondono in modo coerente.
- Nessun endpoint reset resta pubblico.
- Il carico torna normale.
- Page cache e OPcache sono distinte.
Prevenzione
- Integra restart nel deploy.
- Documenta configurazione.
- Usa invalidazione mirata.
- Monitora processi.
- Non creare reset pubblici.
Errori da evitare
- Non confondere HTML cache e bytecode.
- Non usare kill indiscriminati.
- Non lasciare opcache_reset accessibile.
- Non resettare continuamente sotto carico.
- Non presumere che CLI e web condividano la cache.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:
- dominio e versione PHP
- file modificato
- hash e orario
- configurazione OPcache rilevante
- metodo di deploy
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Verifica prolungata dopo la correzione
Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.
Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.
Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.
Domande frequenti su OPcache codice PHP vecchio
opcache_reset elimina la file cache?
La documentazione PHP indica che azzera la cache in memoria, non la file cache.
La CLI resetta OPcache del sito?
Non necessariamente, perché può usare un processo e una configurazione separati.
Devo disattivare OPcache?
No. È preferibile correggere invalidazione e deploy.
Perché solo alcune richieste vedono codice vecchio?
Pool o processi differenti possono avere cache non allineate.
LiteSpeed Page Cache è la stessa cosa?
No. Memorizza risposte HTTP, mentre OPcache memorizza bytecode PHP.