Moodle Cron: configurazione e monitoraggio dei task che fanno funzionare la piattaforma anche quando nessuno sta cliccando.
Email, notifiche, sincronizzazioni, cleanup, plugin, report e altri processi possono dipendere da task eseguiti in background. Se il cron gira non significa automaticamente che tutti i task stiano funzionando correttamente.
Molte funzioni Moodle non vengono eseguite quando l’utente clicca. Aspettano il cron.
Il cron avvia lo scheduler che esegue attività pianificate e processi messi in coda da Moodle e dai plugin. Per questo un problema di scheduling può manifestarsi come email ferme, sincronizzazioni in ritardo o attività automatiche che sembrano non funzionare.
Il cron è il motore. I scheduled task sono i lavori che quel motore deve eseguire.
Non tutti i task sono ricorrenti: alcuni vengono messi in coda quando accade qualcosa.
Gli ad hoc task vengono creati da eventi o processi specifici. Se la coda cresce, rimane arretrata o contiene task che falliscono, il problema può diventare visibile molto dopo l’evento che lo ha generato.
Non ci fermiamo alla configurazione: verifichiamo l’esecuzione reale.
Il cron viene realmente avviato?
Controlliamo esecuzioni, frequenza e presenza di interruzioni.
PHP CLI, utente e path coerenti?
Il comando può esistere ma usare un ambiente differente da quello previsto.
I task arrivano fino in fondo?
Un cron partito non garantisce che ogni task abbia terminato correttamente.
La frequenza va scelta in funzione dei task e dell’operatività della piattaforma.
In ambienti Moodle moderni è generalmente utile una pianificazione frequente, ma l’impostazione va valutata insieme a carico, task, plugin, infrastruttura e requisiti del servizio. Non usiamo una regola universale senza osservare il sistema.
In produzione preferiamo una configurazione server-side controllata e verificabile.
L’obiettivo è evitare che l’esecuzione dipenda da una visita web o da un comportamento non deterministico, mantenendo controllo su ambiente PHP, utente, log e pianificazione.
Approfondisci Server Moodle.
Riavviare il cron senza capire perché il task fallisce può soltanto ripetere l’errore.
“Le email Moodle non partono” non significa automaticamente che il problema sia SMTP.
Cron, task, code, plugin e configurazione email possono concorrere allo stesso sintomo. Seguiamo il processo fino al punto in cui si interrompe.
Approfondisci Assistenza Moodle.
Completion, generazione e invio possono appartenere a passaggi diversi dello stesso flusso.
Quando un attestato dipende da processi asincroni, verifichiamo quale task dovrebbe eseguire l’azione e se la coda viene processata correttamente.
Approfondisci Automazioni Attestati.
SCORM, completion e reporting possono incrociare processi in background che vanno verificati separatamente dal player.
Se il problema riguarda completion o report, controlliamo sia ciò che il pacchetto comunica sia ciò che la piattaforma elabora successivamente.
Link: Moodle SCORM, Reportistica SCORM.
Un report automatico è affidabile soltanto se il processo che lo genera e lo invia viene eseguito puntualmente.
Scheduler, query, generazione file e invio possono essere passaggi distinti. Se uno si blocca, il report può risultare incompleto o non arrivare.
Approfondisci Reportistica eLearning.
Utenti, coorti, iscrizioni e dati esterni possono dipendere da processi pianificati.
Quando una sincronizzazione è in ritardo analizziamo cron, task, plugin, API e sistema remoto senza assumere che il problema sia necessariamente Moodle.
Approfondisci Integrazioni Moodle.
Alcuni flussi vengono elaborati in modo asincrono e richiedono scheduler, code o processi intermedi.
API, webhook e automazioni non dipendono sempre dal cron, ma quando lo fanno analizziamo il processo end-to-end.
Sessioni, cache, dati temporanei, log e processi dei plugin possono richiedere attività periodiche.
Il comportamento dipende dalla versione Moodle e dai plugin installati. Per questo il controllo del cron entra nella manutenzione preventiva della piattaforma.
Un task pesante può produrre query lunghe, lock e picchi di I/O.
Quando il cron diventa lento non guardiamo soltanto lo scheduler: analizziamo query, database, plugin, API esterne e risorse del server.
Approfondisci Ottimizzazione Moodle.
Cache, sessioni e task sono livelli diversi, ma i sintomi di infrastruttura possono sovrapporsi.
Verifichiamo Redis quando il comportamento del sistema indica problemi di cache o sessioni, senza attribuire allo scheduler ciò che appartiene ad altri componenti.
Approfondisci Redis Moodle.
Non basta sapere quanto dura il cron. Bisogna capire cosa sta facendo durante quel tempo.
CPU, RAM, PHP CLI, storage, database e rete possono determinare la capacità di processare task e code entro tempi coerenti.
Approfondisci Server Moodle.
La durata è un sintomo: la diagnosi deve trovare quale lavoro sta consumando il tempo.
Più processi paralleli non significano automaticamente più velocità.
Lock, limiti di concorrenza, risorse disponibili e natura dei task vanno valutati insieme. Il tuning corretto dipende dal carico reale e non da un numero universale.
Un plugin può aggiungere task propri che falliscono solo durante l’esecuzione in background.
Per questo un plugin apparentemente funzionante nell’interfaccia può generare errori durante cron, sincronizzazione o processi differiti.
Approfondisci Plugin Moodle.
Dopo un cambio importante verifichiamo anche scheduler, task e code.
Versione, plugin e task.
Dopo l’upgrade controlliamo che le attività pianificate non presentino nuovi errori.
Aggiornamento Moodle →Il cron va configurato sul nuovo server.
Il trasferimento dei file non garantisce che lo scheduler sia attivo nella nuova infrastruttura.
Migrazione Moodle →Problema già in produzione.
Raccogliamo task, log, tempi e contesto per trovare la causa.
Assistenza Moodle →Non vogliamo scoprire un cron fermo quando qualcuno nota tre giorni dopo che gli attestati non arrivano.
Possiamo monitorare segnali come mancata esecuzione, task troppo vecchi, errori, code anomale e variazioni significative della durata.
Approfondisci Monitoraggio LMS.
Partiamo dal processo che manca, poi seguiamo la catena fino alla causa.
Un processo Moodle non parte automaticamente?
Descrivici cosa dovrebbe succedere, quando dovrebbe succedere e cosa accade invece. Da lì verifichiamo cron, task e dipendenze.
Quando una funzione Moodle “ogni tanto non parte”, il cron è uno dei primi livelli che controllo.
Non per dare la colpa allo scheduler, ma per capire se il processo è stato eseguito, quando, per quanto tempo e con quale risultato.
Seguo personalmente i casi in cui applicazione, plugin, database e infrastruttura devono essere letti insieme per distinguere il sintomo dalla causa.
Cosa dicono i clienti che lavorano con Atlas Learning.
Le recensioni vengono mostrate dinamicamente tramite Trustindex.
Domande frequenti su cron, scheduled task e processi Moodle.
Cos’è il cron di Moodle?
È il meccanismo che permette a Moodle di eseguire processi pianificati e attività in background senza richiedere un’azione diretta dell’utente.
A cosa serve il cron Moodle?
Può essere coinvolto in notifiche, sincronizzazioni, cleanup, processi plugin, report e altre attività automatiche.
Ogni quanto va eseguito?
La frequenza dipende dall’installazione e dai task. In ambienti moderni viene normalmente pianificato con frequenza elevata, valutando sempre carico e architettura.
Come verifico se Moodle cron funziona?
Verifichiamo esecuzioni reali, scheduled task, code, log, ambiente PHP e risultato dei processi.
Perché i scheduled task non partono?
Può dipendere da cron non eseguito, task disabilitato, lock, errore plugin, timeout, dipendenza esterna o infrastruttura.
Cosa sono gli ad hoc task?
Sono processi messi in coda da specifici eventi o componenti e non necessariamente eseguiti secondo una pianificazione ricorrente.
Perché il cron Moodle è lento?
Task arretrati, plugin, query, storage, API esterne e risorse server possono aumentare la durata complessiva.
Un plugin può bloccare o rallentare il cron?
Un plugin può aggiungere task propri che generano errori o elaborazioni pesanti. Va verificato il task specifico.
Il cron può causare problemi alle email?
Alcune notifiche o code email possono dipendere da processi schedulati, ma SMTP e configurazione email restano componenti distinti da verificare.
Gli attestati dipendono dal cron?
Dipende dal plugin e dal flusso implementato. Generazione o invio possono essere asincroni e quindi dipendere da task.
Posso monitorare automaticamente il cron?
Sì. Possiamo progettare monitoraggio su mancata esecuzione, errori, code anomale e durata.
Dopo una migrazione bisogna riconfigurare il cron?
Va verificato sul nuovo server. Il trasferimento di Moodle non garantisce che la pianificazione del sistema operativo sia stata ricreata.
Il cron Moodle può sovraccaricare il server?
Task pesanti o code arretrate possono produrre carico significativo. Per questo cron, database e server vanno analizzati insieme.
Potete correggere task Moodle falliti?
Sì. Possiamo analizzare log, plugin, dipendenze e infrastruttura per individuare la causa del fallimento.
Quale processo dovrebbe essere eseguito automaticamente e cosa succede invece?
Il task non parte, fallisce oppure termina ma il risultato atteso non viene prodotto? Sono tre scenari diversi e la diagnosi parte da questa distinzione.