Moodle cron non funziona: isolare se il processo non parte, resta in lock o accumula task senza svuotare la coda.
Partiamo da crontab e admin/cli/cron.php, poi leggiamo scheduled task, adhoc queue, lock e durata reale dei job.
Email in ritardo, completion bloccata e report fermi: spesso il cron non chiude i task.
Il sintomo tipico non e una schermata rossa: e silenzio operativo. Notifiche assenti, task queued, ultima esecuzione in Site administration che non avanza.
Checklist prima di toccare plugin o alzare CPU.
Frequenza reale
Confronta crontab/systemd con last run in Amministrazione > Server > Task pianificati.
CLI coerente
Esegui php admin/cli/cron.php con lo stesso binary PHP del sito e leggi exit code.
Coda e lock
Conta adhoc in ritardo e task running/failing oltre soglia.
Dove guardare: log dello scheduler di sistema.
journalctl del timer, /var/log/cron, syslog o History di Task Scheduler: il comando deve partire all’intervallo dichiarato.


Esecuzione manuale CLI per isolare permessi e path.
Se la CLI fallisce subito e ambiente PHP/utente. Se gira ma i task no, scendi in scheduled/adhoc.
UI dei task pianificati e fail_delay.
Annota last run, fail_delay e componenti che monopolizzano il tempo di cron.


Possibile causa: nessuno invoca il cron regolarmente.
Hosting senza crontab, container senza sidecar, URL cron web spento dopo hardening.
Possibile causa: lock di cron o task appeso.
Processo killato a meta; nuovi run escono subito. Cerca PHP residui e stato lock.


Possibile causa: adhoc che crescono piu veloci del consumo.
Mail massive, rebuild completion, plugin chiassosi: il cron ‘gira’ ma non smaltisce.
Possibile causa: timeout o OOM a meta job.
Nei log CLI: terminated / memory exhausted negli orari del cron.


Possibile causa: utente CLI diverso da www-data su moodledata.
File creati da root non gestibili dal web: cache e sessioni intermittenti.
Correzione: una sola invocazione CLI affidabile.
Job dedicato a php admin/cli/cron.php; evita doppio URL+CLI.


Correzione: lock solo dopo processi fantasma.
Termina orfani, poi sblocca con procedura della versione Moodle, con snapshot.
Correzione: riprogrammare task che saturano.
Fuori picco, update plugin, spezza batch adhoc.


Correzione: memory_limit/timeout del binary CLI.
Allinea php.ini CLI alla realta dei job notturni.
Verifica: tre cicli con coda in calo.
15-30 minuti: adhoc down, scheduled ok, email/completion ripartite.


Allerta su last cron e soglia adhoc.
Non scoprire il fermo solo quando mancano attestati.
Backlog strutturale: mappa dipendenze plugin.
Atlas Learning riduce carico con evidenze, non riavvii ciechi.


Sul cron Moodle parto da cosa non succede piu in piattaforma, non dal server a caso.
Ricostruisco crontab, CLI, task ed effetto utente prima di proporre modifiche.
Atlas Learning opera come partner tecnico: leggiamo log, riproduciamo il caso e interveniamo sul livello responsabile, senza sostituirci alla vostra governance di piattaforma.
Cosa dicono i clienti che lavorano con Atlas Learning.
Le recensioni vengono mostrate dinamicamente tramite Trustindex.
Domande frequenti su Moodle cron non funziona.
Basta il cron via URL?
In ambienti hardenizzati preferiamo CLI schedulata: permessi e log piu chiari.
Cron parte ma email no?
Puo essere coda task oppure SMTP: vanno separate le diagnosi.
Serve root?
Non sempre. Crontab si; molti check bastano con accesso app e log.
Fix in produzione?
Solo con causa isolata e verifica. Siamo partner tecnico, non patch casuali.
Last run fermo o coda che non cala?
Invia versione Moodle, output CLI cron, screenshot task e orario del fermo.