Cronjob non funziona: cause e soluzioni

Hai impostato un cron job in cPanel, ma l'attività prevista non viene eseguita? Allora dovresti controllare separatamente la pianificazione, il comando e lo script richiamato.

Un errore particolarmente comune durante la diagnosi consiste nell'equiparare automaticamente un cron job non funzionante a una pianificazione errata. In realtà, cPanel può avviare correttamente il cron job, mentre a fallire è solo il comando eseguito o lo script richiamato.

In questa guida ti mostriamo come investigare in modo sistematico su un cron job non funzionante e trovare errori tipici relativi a pianificazione, percorsi, versione di PHP, permessi, output e WP-Cron di WordPress.

Regola fondamentale: Verifica prima se il cronjob viene avviato. Dopodiché verifica se il comando inserito funziona. Solo dopo esamini l'applicazione vera e propria. In questo modo eviti modifiche su più livelli tecnici contemporaneamente.

I tre livelli di un problema di cronjob #

Per una ricerca degli errori pulita, dovresti distinguere tre aree:

1. Pianificazione
   ↓
Il cronjob viene avviato al momento previsto?

2. Comando
   ↓
Il comando inserito può essere eseguito?

3. Applicazione
   ↓
Lo script richiamato funziona correttamente di per sé?

Questa distinzione è fondamentale.

Un cronjob, ad esempio, può essere avviato puntualmente, ma interrompersi immediatamente a causa di un percorso di file errato. Allo stesso modo, PHP può essere avviato correttamente, mentre lo script PHP stesso genera un errore fatale.

1. Controllare i cronjob in cPanel #

Accedi al tuo cPanel di CURIAWEB e apri:

Opzioni avanzate → Cronjob

Verifica prima se il cronjob in questione è effettivamente presente nell'elenco dei cronjob esistenti.

Controlla quindi la voce completa, in particolare il programma e il comando.

Se non sei ancora sicuro di come configurare correttamente un cronjob, troverai le basi su Creare un Cronjob in cPanel e impostare correttamente la pianificazione.

2. Verificare attentamente il cronoprogramma #

Un programma cron è composto da cinque campi:

Minuto Ora Giorno Mese Giorno della settimana

Un cron job giornaliero alle 03:00, ad esempio, può avere questo aspetto:

0 3 * * *

Un cron job ogni cinque minuti:

*/5 * * * *

Controlla i valori carattere per carattere.

Ho confuso i minuti con le ore #

Un errore comune è lo scambio dei primi due campi.

Per esempio:

30 3 * * *

significa fondamentalmente ogni giorno alle 03:30.

L'ordine non è ora e minuto, bensì:

Minuto → Ora

Non confondere il giorno del mese con il giorno della settimana #

Anche questi due campi hanno significati diversi.

Per esempio:

0 6 * * 1

significa fondamentalmente un'esecuzione il lunedì alle ore 06:00.

Contro:

0 6 1 * *

equivale sostanzialmente a un'esecuzione il primo giorno del mese alle ore 06:00.

3. Considerare l'ora del server o il fuso orario #

Se il cronjob funziona ma sembra venga eseguito all'ora sbagliata, dovresti controllare il fuso orario rilevante per l'esecuzione del cron.

L'ora locale del computer e quella utilizzata dal server non devono necessariamente coincidere.

Consiglio pratico: Se un cron job viene eseguito in modo affidabile, ma si discosta sempre di una o due ore dall'orario previsto, ad esempio, il fuso orario è uno dei primi punti da controllare.

Osservare l'ora legale e solare #

Per i compiti che devono tassativamente essere eseguiti a una determinata ora locale, può essere rilevante anche il passaggio dall'ora solare all'ora legale e viceversa.

Non modificare quindi immediatamente e per puro sospetto un programma altrimenti funzionante, qualora il tempo di esecuzione osservato sia cambiato.

4. Controllare il comando Cron completo #

Se il programma è corretto, controlla il comando effettivo.

Un cron job in PHP può essere strutturato schematicamente, ad esempio, in questo modo:

/percorso/del/php-binary /home/CPANELUSER/public_html/script.php

Anche un solo carattere errato, una directory inesistente o un binario PHP non corretto possono fare in modo che il comando non funzioni.

Importante: Non usare semplicemente un comando cron dalla guida di un altro provider di hosting. I percorsi PHP e le strutture delle directory possono variare.

5. Controllare i percorsi assoluti #

I cronjob dovrebbero funzionare possibilmente con percorsi assoluti univoci.

Un percorso di file può apparire schematicamente così:

/home/CPANELUSER/public_html/script.php

Un inserimento come:

script.php

è invece un percorso relativo e presuppone che venga utilizzata la directory di lavoro corretta.

Proprio questa ipotesi può essere errata durante un'esecuzione automatica di cron.

Document Root errato #

In un account di hosting con più domini, un sito web non deve necessariamente trovarsi sotto public_html trovare.

Un dominio o sottodominio aggiuntivo può ad esempio possedere una propria Document Root.

Se il cronjob richiama un file del sito web sbagliato o di una directory errata, il comando potrebbe fallire o addirittura interagire con un'altra installazione.

Puoi visualizzare la struttura delle directory con Gestione file di cPanel controllare.

6. Verificare che il file esista effettivamente #

Apri la directory specificata nel cronjob nel File Manager di cPanel.

Controlla:

• Il file esiste?
• Il nome del file è esattamente corretto?
• Le maiuscole e le minuscole sono corrette?
• Il file si trova nella directory specificata?

I file system Linux fanno fondamentalmente distinzione tra maiuscole e minuscole.

Ad esempio, possono:

cron.php
Cron.php
CRON.php

essere nomi di file diversi.

7. Risolvere „No such file or directory“ #

Un messaggio come:

Nessun file o directory

indica spesso che un file o un programma specificato non è stato trovato nel percorso utilizzato.

Verifica quindi in particolare:

• Percorso del binario PHP
• Percorso dello script
• Nome file
• Document Root
• se il file è stato spostato dopo una migrazione

8. Risoluzione di „Command not found“ #

Un messaggio come:

comando non trovato

significa fondamentalmente che il comando chiamato non è stato trovato.

Questo può accadere, ad esempio, se un cronjob si limita a:

php script.php

utilizzato e basandosi sul fatto che il PHP desiderato venga trovato automaticamente tramite il percorso di ricerca.

Nei cronjob è più affidabile utilizzare l'eseguibile effettivamente necessario o il comando completo previsto dall'applicazione.

9. Verifica il binario PHP #

Per i cron job in PHP, bisogna chiarire quale versione di PHP deve eseguire lo script.

La versione PHP di un sito web e la versione PHP di una chiamata da riga di comando non sono automaticamente identiche.

Se, ad esempio, il tuo sito web funziona con una specifica versione di PHP, ma il cron job utilizza un eseguibile PHP diverso, lo script potrebbe generare errori quando viene eseguito automaticamente.

La versione PHP di un dominio viene gestita in CURIAWEB fondamentalmente tramite il MultiPHP-Manager.

Importante: Il MultiPHP Manager determina la configurazione PHP web del dominio. Nel caso di un cron job CLI, è comunque necessario verificare separatamente quale binario PHP viene richiamato nel comando del cron.

10. Non indovinare la versione PHP del cronjob con php -v #

Un appello generale come:

php -v

mostra la versione PHP del comando CLI risolto.

Questo non dimostra automaticamente che:

• il sito web utilizza la stessa versione PHP
• il cronjob utilizza lo stesso binario PHP
• le estensioni PHP richieste sono identiche

Ciò che è determinante è il comando effettivamente utilizzato nel cronjob.

11. Controllo delle estensioni PHP mancanti #

Uno script PHP può essere installato correttamente e tuttavia fallire se l'ambiente PHP utilizzato non fornisce un'estensione necessaria.

I messaggi di errore tipici possono indicare classi o funzioni inesistenti.

Verifica poi innanzitutto quale versione di PHP o quale ambiente PHP viene effettivamente utilizzato dal cron job.

Puoi trovare ulteriori informazioni su Attivare e gestire le estensioni PHP in cPanel.

12. Tenere conto di diverse configurazioni PHP #

Uno script PHP può funzionare tramite il sito Web e mostrare comunque un comportamento diverso tramite un cron job da CLI.

Il motivo potrebbe essere che PHP Web e PHP CLI utilizzano configurazioni diverse.

Ciò può includere, ad esempio, differenze in:

Versione PHP
Estensioni PHP
memory_limit
File di configurazione
Variabili d'ambiente

appartenere.

Pertanto, non trasferire automaticamente ogni impostazione PHP del web a un cronjob CLI.

13. Correggere „Permission denied“ #

Un messaggio come:

Permesso negato

indica un problema di autorizzazione.

La causa esatta dipende da ciò che deve essere eseguito o aperto.

Verifica in particolare:

• Permessi dei file
• Autorizzazioni di directory
• sia che lo script venga eseguito direttamente o richiamato tramite un interprete
• se lo script deve scrivere o modificare file

Le basi si possono trovare su Impostare correttamente i permessi dei file 644 e 755 in cPanel.

Attenzione: Non impostare i permessi dei file in modo indiscriminato su 777, per aggirare un errore. In questo modo la causa principale non viene risolta correttamente e la configurazione può diventare inutilmente insicura.

14. Verificare se lo script richiede i diritti di scrittura #

Un cron job può avviare con successo lo script PHP, mentre lo script stesso fallisce durante la scrittura di un file.

Ciò riguarda, ad esempio, i processi che:

• Genera file di cache
• Esporta salvataggi
• Sposta i file di importazione
• Scrittura di file di log
• creare file temporanei

Verifica quindi le autorizzazioni della specifica directory di destinazione.

Non scartare subito l'output di Cron #

Durante la risoluzione dei problemi, l'output del cronjob è una delle fonti di informazioni più importanti.

Se il tuo comando inizia ad esempio con:

> /dev/null 2>&1

vengono scartati l'output standard e l'output di errore.

Questo è sfavorevole in caso di un cronjob difettoso.

Consiglio pratico: Durante la diagnosi, rimuovi temporaneamente qualsiasi soppressione dell'output configurata intenzionalmente, purché ciò sia sensato e sicuro per il comando in questione. In questo modo potrai vedere il messaggio di errore effettivo.

16. Distinguere tra standard output e standard error #

I comandi Linux possono fondamentalmente utilizzare due canali di output rilevanti:

stdout
→ output normale

stderr
→ messaggi di errore

Se viene reindirizzato solo l'output normale, un messaggio di errore potrebbe comunque comparire altrove.

L'ortografia:

2>&1

reindirizza l'output degli errori verso la stessa destinazione dell'output standard.

17. Registrare temporaneamente l'output di Cron #

Quando si utilizza un proprio script, per fini diagnostici può essere utile scrivere temporaneamente gli output in un file di log.

Schematicamente:

COMANDO >> /home/CPANELUSER/logs/cron-test.log 2>&1

In questo modo l'output standard e i messaggi di errore vengono aggiunti a un file.

Usa un percorso esistente e scrivibile.

Importante: Un tale file di log di diagnostica dovrebbe essere controllato e, dopo la risoluzione dei problemi, rimosso o gestito in modo sensato. I cronjob eseguiti frequentemente possono far crescere rapidamente i file di log.

18. Controllare le uscite e-mail del cronjob #

cPanel può inviare l'output dei cron job a un indirizzo e-mail configurato.

Se usi questa funzione, controlla anche la cartella spam della cassetta postale in questione.

Una e-mail di cron può contenere, ad esempio, un messaggio di errore che indica direttamente un percorso errato o un errore PHP.

19. Eseguire manualmente il cronjob #

Se disponi dell'accesso SSH e il comando può essere eseguito manualmente senza rischi, un test manuale è molto utile.

Esegui il più precisamente possibile il comando inserito anche nel cronjob.

Con questo puoi distinguere due casi:

Il comando non funziona manualmente
→ Il problema risiede probabilmente nel comando o nello script

Il comando funziona manualmente
→ Esaminare più attentamente l'ambiente Cron o la pianificazione

Attenzione: Non eseguire più volte a titolo di prova un'importazione, un processo di spedizione, un processo di pagamento o qualsiasi altra attività che modifichi i dati, se non conosci il loro comportamento in caso di ripetizione.

Funziona manualmente – non come cronjob #

Se lo stesso comando funziona in una shell interattiva ma non come cron job, dovresti esaminare in particolare l'ambiente di esecuzione.

I cronjob potrebbero non avere le stesse variabili d'ambiente della tua sessione SSH interattiva.

Rilevanti sono, ad esempio:

• Percorso
• Directory di lavoro
• PHP-Binary
• ulteriori variabili d'ambiente

Utilizza quindi percorsi il più possibile completi per programmi e file.

21. Verifica della directory di lavoro dello script #

Alcuni script utilizzano internamente percorsi di file relativi.

Per esempio:

include 'config.php';

oppure si aspettano file relativi alla directory di lavoro corrente.

Se lo script viene avviato in un altro ambiente, ciò potrebbe causare problemi.

Un'applicazione robusta dovrebbe gestire i percorsi necessari in modo univoco. Nel caso di un'applicazione di terze parti, dovresti usare la sua istruzione cron designata.

22. La chiamata HTTP funziona, la chiamata CLI no #

Molte applicazioni forniscono un URL per le operazioni cron.

Una chiamata HTTP e una chiamata PHP-CLI diretta non sono tecnicamente identiche.

HTTP:
Cron → HTTP/HTTPS → Webserver → Applicazione

CLI:
Cron → PHP-Binary → Script PHP

Se il produttore prevede espressamente una chiamata HTTP, non dovresti sostituirla con una chiamata PHP diretta senza un motivo tecnico.

23. La CLI funziona, la chiamata HTTP no #

Viceversa, una chiamata PHP diretta potrebbe funzionare, mentre una chiamata HTTP fallisce.

Durante una chiamata HTTP vengono aggiunti componenti aggiuntivi:

• DNS
• Server web
• HTTPS
• Reindirizzamenti
• Controllo degli accessi
• Routing delle applicazioni

Verifica quindi quale modalità di chiamata l'applicazione effettivamente preveda.

24. Il cronjob HTTP riceve 403 Forbidden #

Quando un cronjob richiama un URL e un:

403 Proibito

riceve, la chiamata HTTP raggiunge fondamentalmente il server web, ma non viene autorizzata come previsto.

La causa può risiedere, ad esempio, nella protezione degli accesso, nelle norme di sicurezza o nell'applicazione.

Trattiamo la diagnosi sistematica alla voce Risolvere l'errore 403 Forbidden.

25. Il cronjob HTTP riceve un errore 500 Internal Server Error #

Uno:

Errore interno del server

indica un errore lato server durante l'elaborazione.

In questo caso il cronjob potrebbe essere stato avviato correttamente. L'errore si verifica solo durante la chiamata HTTP o all'interno dell'applicazione.

Ulteriori passaggi sono disponibili su Risolvere l'errore 500 Internal Server Error.

Analizzare un errore fatale PHP #

Se l'output contiene un errore fatale PHP, di solito il problema principale non è la pianificazione.

Quindi è determinante il messaggio di errore PHP specifico.

Le possibili cause includono, ad esempio:

• versione PHP incompatibile
• estensione PHP mancante
• codice applicativo difettoso
• file mancante
• Problema di memoria

Non modificare più impostazioni PHP contemporaneamente, ma procedi in base al messaggio di errore specifico.

27. „Superato il limite di memoria consentito“ #

Un messaggio come:

Dimensione di memoria consentita ... esaurita

indica che il processo PHP ha raggiunto il limite di memoria disponibile.

Verifica assolutamente quale ambiente PHP esegue il cron job.

Le impostazioni PHP web di un dominio non si applicano automaticamente a un processo PHP CLI.

Le basi sui limiti di PHP si trovano su Imposta limite di memoria PHP, dimensione di caricamento e tempo di esecuzione.

28. Classificare correttamente durata e timeout #

Se un cron job si interrompe durante un'attività più lunga, la durata dell'esecuzione potrebbe avere un ruolo.

Fai una distinzione tra:

• Limiti dell'ambiente PHP utilizzato
• Limiti e comportamento dell'applicazione
• servizi esterni
• Risorse di hosting

Un processo CLI non si comporta necessariamente allo stesso modo di una normale chiamata a una pagina web per quanto riguarda i limiti di PHP.

29. L'API esterna non risponde #

Un cronjob può funzionare tecnicamente in modo corretto e tuttavia non completare il proprio compito se lo script dipende da un servizio esterno.

Gli esempi sono:

• API esterne
• Sistemi di gestione di magazzino
• Sistemi CRM
• Servizi di pagamento
• fonti di dati esterne

In questo caso, controlla l'output o il log dell'applicazione per verificare la presenza di errori di connessione, problemi di autenticazione o timeout.

30. Controllare le credenziali di accesso o le chiavi API #

Quando un cronjob scambia dati con un sistema esterno, la causa potrebbe essere costituita da credenziali non valide o scadute.

Irrori tipici sono, ad esempio:

Non autorizzato
Autenticazione fallita
Chiave API non valida
Accesso negato

Non salvare credenziali sensibili non protette direttamente nel comando cron.

31. Il cronjob si avvia troppo spesso #

Un cronjob può funzionare tecnicamente e tuttavia causare problemi se viene avviato troppo frequentemente.

Esempio:

Inizio alle 5 minuti
Durata 12 minuti

È quindi possibile avviare una nuova istanza mentre quella precedente è ancora in esecuzione.

Riconoscimento di processi sovrapposti #

Diverse istanze eseguite contemporaneamente possono, ad esempio, causare i seguenti problemi:

• doppia elaborazione
• file bloccati
• Conflitti di database
• elevato utilizzo della CPU
• maggior consumo di memoria
• limiti API esterni

Verifica quindi, per le attività a lunga esecuzione, se l'intervallo corrisponde alla durata effettiva.

Proteggere l'applicazione contro l'esecuzione parallela #

Le applicazioni professionali utilizzano meccanismi per determinati compiti che possono impedire l'esecuzione parallela.

Ciò può avvenire, ad esempio, tramite file di blocco, stati del database o altri meccanismi di blocco.

Non implementare tali meccanismi a titolo precauzionale in applicazioni di terze parti. Prima consulta la loro documentazione.

Controllo delle risorse di hosting #

Un cronjob può consumare CPU, memoria, processi e risorse del database.

Pertanto, in caso di attività frequenti o estese, l'utilizzo delle risorse può essere rilevante.

Ti spieghiamo come controllare i valori di CloudLinux su Comprendere l'utilizzo delle risorse di CloudLinux in cPanel.

Limite delle risorse raggiunto #

Se il tuo sito web o la tua applicazione mostra contemporaneamente indicazioni di risorse di hosting esaurite, ciò dovrebbe essere esaminato separatamente.

Un cronjob può innescare un picco di carico o coincidere con un carico elevato già esistente.

Trattiamo la diagnosi mirata presso Limite di risorse raggiunto: identificazione e risoluzione dei limiti di CloudLinux.

36. Diversi cronjob si avviano contemporaneamente #

Se diversi cronjob intensivi di risorse si avviano esattamente nello stesso minuto, può crearsi un picco di carico inutile.

Per esempio:

03:00 → Importazione
03:00 → Esportazione
03:00 → Sincronizzazione
03:00 → Elaborazione statistica

Se le applicazioni sono flessibili nel tempo, orari di avvio diversi possono avere più senso.

Non modificare gli intervalli predefiniti di un'applicazione senza prima verificarli.

37. Il cronjob non funziona più dopo il trasferimento del sito web #

Dopo un trasferimento di hosting o di un sito web, i cron job rientrano tra le configurazioni che dovrebbero essere controllate separatamente.

Soprattutto i percorsi assoluti potrebbero essere cambiati.

Ad esempio, un vecchio cronjob potrebbe continuare a puntare su:

/home/ALTERUSER/...

mostrare, sebbene l'applicazione si trovi ora sotto un percorso di account diverso.

38. Controllare il cronjob dopo il cambio di dominio #

Se il cronjob richiama un URL, anche un cambio di dominio può essere rilevante.

Controlla poi:

• Nome host
• HTTPS
• Reindirizzamenti
• Percorso dell'URL Cron
• Controllo degli accessi

Un vecchio cron job HTTP potrebbe altrimenti continuare a chiamare un indirizzo non più valido.

39. Il cronjob non funziona più dopo il cambio di versione di PHP #

Se il problema si verifica subito dopo una modifica della versione di PHP, dovresti verificare quale binario PHP sta usando il cronjob.

Un percorso CLI impostato in modo fisso non viene necessariamente adattato in modo automatico modificando la versione PHP del web.

Verifica inoltre se l'applicazione e le relative estensioni richieste sono compatibili con la versione di PHP utilizzata.

Il cronjob non funziona più dopo l'aggiornamento #

Se un'applicazione smette di elaborare correttamente il suo compito cron immediatamente dopo un aggiornamento, annota:

• quale applicazione è stata aggiornata
• quale versione è stata utilizzata in precedenza
• quale versione viene utilizzata adesso
• quale messaggio di errore genera il cronjob

Verifica quindi la documentazione o i requisiti di sistema dell'applicazione.

Non modificare contemporaneamente la sintassi Cron, la versione PHP e i permessi dei file se l'errore è chiaramente iniziato solo dopo un aggiornamento software.

41. Il WP-Cron di WordPress non funziona #

WordPress utilizza come impostazione predefinita WP-Cron per le attività pianificate.

WP-Cron non è un classico cronjob di Linux. Per impostazione predefinita, le attività pianificate vengono avviate in concomitanza con le visite al sito web.

Se i compiti di WordPress vengono eseguiti in ritardo o non vengono eseguiti affatto, dovresti quindi verificare innanzitutto se:

• viene utilizzato il WP-Cron normale
• WP-Cron è stato disattivato consapevolmente
• è stato configurato un vero cron server come sostituto
• questo cron del server funziona davvero

42. Controllare DISABLE_WP_CRON #

Nel file WordPress wp-config.php può essere presente, ad esempio, la seguente impostazione:

define( 'DISABLE_WP_CRON', true );

Questo disabilita il normale meccanismo di chiamata di WordPress per WP-Cron.

Questo ha senso solo se è stato impostato consapevolamente un altro meccanismo affidabile per le attività pianificate di WordPress.

Attenzione: Rimuovi o modifica DISABILITA_WP_CRON non cieco. Verifica prima perché l'impostazione è stata configurata e se esiste un cronjob del server come sostituto.

43. Server-Cron per WordPress presente, ma le attività comunque non vengono eseguite #

Se un vero cronjob deve attivare regolarmente WordPress, verifica prima se questo stesso cronjob viene eseguito con successo.

Successivamente occorre verificare se WordPress elabora effettivamente i compiti in scadenza.

Con questo separi di nuovo:

Il server-cron funziona?
        ↓
WordPress viene raggiunto?
        ↓
WP-cron elabora le attività in scadenza?
        ↓
La singola applicazione elabora la sua attività?

Attività di WooCommerce non eseguita #

WooCommerce e le estensioni possono utilizzare attività di background pianificate.

Se una determinata attività del negozio non viene eseguita, non significa automaticamente che il cronjob di cPanel sia difettoso.

Verifica prima a quale livello viene pianificata ed elaborata la rispettiva attività.

Nei sistemi WordPress/WooCommerce, può avere un ruolo anche il sistema interno per le azioni programmate.

45. Un cronjob invia una grande quantità di email #

Quando un cronjob attiva delle e-mail, dovresti essere particolarmente prudente durante i test.

Un test cron job impostato su ogni minuto potrebbe altrimenti attivare ripetutamente la stessa funzione di invio.

Attenzione: Non utilizzare un intervallo di test aggressivo per i processi di spedizione, newsletter, fatturazione o notifica, a meno che tu non sappia come l'applicazione impedisce le esecuzioni multiple.

46. Il cronjob genera record duplicati #

I dati duplicati possono essere un'indicazione del fatto che:

• il cronjob è stato configurato più volte
• eseguire più processi identici in parallelo
• l'applicazione stessa non possiede alcuna protezione contro la doppia elaborazione
• un cron del server e un altro schedulatore attivano la stessa attività

Controlla prima l'elenco dei cronjob esistenti e successivamente la configurazione dell'applicazione.

47. Verificare se lo stesso cronjob è presente due volte #

Controlla sotto:

Opzioni avanzate → Cronjob

che lo stesso comando o uno pressoché identico sia stato inserito più volte.

Questo può accadere, ad esempio, dopo una migrazione o una nuova configurazione manuale.

Elimina una voce solo se sai con certezza che si tratta effettivamente di un duplicato non necessario.

Cronjob eliminato #

Se un'applicazione improvvisamente non elabora più le attività pianificate, controlla anche se il cronjob necessario è ancora presente.

Ciò può essere rilevante, ad esempio, dopo una pulizia, una migrazione o una modifica manuale.

Un cron job eliminato non viene ripristinato automaticamente dal solo fatto che l'applicazione è ancora installata.

49. Vecchi cronjob dopo la disinstallazione di un'applicazione #

Al contrario, i cron job possono rimanere attivi anche se l'applicazione corrispondente non esiste più.

Il cronjob può quindi chiamare regolarmente un percorso non più esistente e generare continuamente messaggi di errore.

Verifica quindi, durante la rimozione di un'applicazione, se i relativi cronjob sono ancora necessari.

50. Non riparare il cronjob andando a tentativi continui #

Se un cronjob non funziona, non dovresti contemporaneamente:

Modifica la pianificazione
Modifica la versione PHP
Modifica i permessi dei file
Sposta lo script
Modifica i limiti PHP
Sostituisci il comando cron

Dopodiché è quasi impossibile stabilire quale modifica sia stata effettivamente rilevante.

Lavora invece dal cronjob all'applicazione:

Programma
→ Comando
→ Percorsi
→ Ambiente di esecuzione
→ Messaggio di errore
→ Applicazione

Classificare correttamente i messaggi di errore tipici #

Messaggio di errore / Problema	Prima controlla
comando non trovato	Comando e percorso completo del file eseguibile
Nessun file o directory	Percorso file, nome file e document root
Permesso negato	Diritti di file e directory e modalità di esecuzione
Errore fatale di PHP	specifico messaggio PHP, versione PHP e applicazione
Dimensione della memoria consentita esaurita	Ambiente PHP e fabbisogno di memoria
Il cronjob viene eseguito all'ora sbagliata	Programma e fuso orario
Funziona manualmente, non via cron	percorsi assoluti e ambiente cron
Chiamata HTTP restituisce 403	Protezione degli accessi, norme di sicurezza e applicazione
La chiamata HTTP restituisce 500	Errori di server, PHP e applicazione e log
L'attività viene eseguita due volte	cron job duplicati e processi sovrapposti
Dopo il trasferimento Cron non funziona	percorsi assoluti e dominio
Dopo il cambio di PHP il cron non funziona	Binario PHP ed estensioni richieste

Diagnosi sistematica in dieci passaggi #

1. Apri Opzioni avanzate → Cronjob e controlla se il cronjob è presente.
2. Controlla minuto, ora, giorno, mese e giorno della settimana.
3. Tieni conto del fuso orario determinante per l'esecuzione.
4. Controlla il comando completo.
5. Controlla tutti i percorsi assoluti di file e programmi.
6. Verificare il binario PHP utilizzato negli script PHP.
7. Rimuovi, se necessario per la diagnosi, la soppressione dell'output configurata intenzionalmente.
8. Prendi nota del messaggio di errore completo.
9. Esegui il comando manualmente, se è sicuro farlo.
10. Esamina solo successivamente l'applicazione stessa.

Se non è presente alcun messaggio di errore #

Se non ricevi alcun output, dovresti prima verificare se questo viene deliberatamente soppresso.

Cerca nel comando cron, ad esempio:

/dev/null

Verifica inoltre se gli output di cron vengono inviati via e-mail e se l'applicazione dispone di un proprio file di log.

Con un proprio script, una registrazione temporanea e controllata può essere utile.

Quando il cronjob funziona in modo sporadico #

Un cronjob che non fallisce sempre richiede una considerazione diversa rispetto a un comando fondamentalmente errato.

In caso di problemi sporadici, verifica in particolare:

• Utilizzo delle risorse
• durata
• processi sovrapposti
• API esterne
• Dipendenze di rete
• dati di input variabili
• Log di applicazione al momento specifico dell'errore

Annota possibilmente il momento esatto di un errore. In questo modo i log e i valori delle risorse possono essere associati molto meglio.

Interpretare correttamente il registro degli errori di cPanel #

In caso di errori di un'applicazione richiamata tramite il server web, il registro degli errori di cPanel può contenere indicazioni importanti.

Spiegheremo i risultati su Leggere il log degli errori di cPanel e trovare gli errori del sito web.

Tuttavia, un cron job eseguito direttamente tramite PHP-CLI non deve necessariamente registrare i suoi errori nello stesso log del server web. Pertanto, dovresti controllare anche l'output del cron e i log specifici dell'applicazione.

Quando dovresti contattare il supporto di CURIAWEB? #

Se hai controllato la pianificazione, il comando, i percorsi e gli output, ma il cronjob continua a non funzionare come previsto, documenta il problema nel modo più specifico possibile.

Per un'analisi tecnica sono particolarmente utili le seguenti informazioni:

• dominio o applicazione interessati
• programma cron impostato
• comando cron completo senza dati riservati
• comportamento atteso
• comportamento effettivo
• ora approssimativa o esatta dell'ultima esecuzione non riuscita
• messaggio di errore completo
• binario PHP o versione PHP utilizzata, se pertinente
• se il comando identico funziona manualmente
• se il cronjob funzionava prima
• quale modifica è stata apportata immediatamente prima del problema

Avviso di sicurezza: Rimuovi password, chiavi API, token e altre credenziali di accesso dal comando cron prima di condividerlo. Non trasmettere tali informazioni riservate inutilmente.

Riepilogo #

Se un cron job non funziona, per prima cosa dovresti determinare a quale livello si verifica il problema. Un cron job non consiste solo nella sua pianificazione: cPanel avvia un comando che a sua volta esegue uno script o un'altra applicazione.

Controlla quindi prima la pianificazione Cron e il fuso orario. Verifica poi il comando completo, i percorsi assoluti e, nel caso di script PHP, il binario PHP effettivamente utilizzato.

Notizie come comando non trovato, Nessun file o directory o Permesso negato forniscono già importanti indicazioni sulla causa. I PHP Fatal Errors devono invece essere analizzati in base al messaggio PHP specifico.

Non sopprimere prematuramente i messaggi di errore durante la diagnosi con /dev/null. L'output dei cron job, i file di log e un test manuale controllato sono spesso i modi più rapidi per risalire alla causa.

Se un comando funziona manualmente ma non come cron job, dovresti considerare in particolare i percorsi assoluti, il binario di PHP, la directory di lavoro e le variabili d'ambiente.

In WordPress bisogna inoltre distinguere tra il WP-Cron nativo di WordPress e un vero cronjob del server. È DISABILITA_WP_CRON attivato, deve essere presente un meccanismo alternativo funzionante.

In caso di errori sporadici, dovresti inoltre esaminare il consumo di risorse, i processi sovrapposti e le dipendenze esterne.

La regola più importante per una ricerca errori efficiente è: Non cambiare tutto contemporaneamente. Controlla programma → comando → percorsi → ambiente di esecuzione → messaggio di errore → applicazione esattamente in questo ordine.