Fix ownCloud Cron Job Not Running: Set Up a Reliable systemd Timer

You open ownCloud’s admin page and see that background jobs have not run recently, or cleanup, activity, external-storage, and other queued tasks seem delayed. A common reaction is to edit cron.php or add another crontab entry. On current ownCloud Server documentation, that is not the best starting point: ownCloud recommends the Cron background mode and the occ system:cron command. A systemd timer can provide the scheduling layer instead of traditional crontab on a Linux host.

This guide focuses on a package or bare-metal style installation where ownCloud lives under a path such as /var/www/owncloud. If you use ownCloud’s official Docker image, stop before creating a host timer: ownCloud documents that the image already configures cron internally, controlled by variables such as OWNCLOUD_CROND_ENABLED and OWNCLOUD_CROND_SCHEDULE. See the current ownCloud background jobs documentation.

What is verified, what depends on your server, and what still needs checking

• Verified: ownCloud recommends Cron rather than AJAX for reliable background execution, and documents occ system:cron as the command to execute queued background jobs.
• Depends on your installation: the ownCloud directory, PHP binary, web-server account, PHP environment, and whether you run a package install, container, appliance, or custom deployment.
• Not knowable from a generic guide: why your current job failed. It may be a scheduler problem, but it can also be permissions, a wrong path, a different PHP CLI configuration, database connectivity, file locking, or an application-level background job failure.

Action: do not create a timer until the exact ownCloud command works manually under the same account that the timer will use.

Step 1: Confirm Cron mode and test ownCloud manually

For a typical Apache/Debian-style installation, the web user is www-data. Replace both the user and path if your environment differs.

sudo -u www-data /var/www/owncloud/occ background:cron
sudo -u www-data /var/www/owncloud/occ system:cron

The first command selects ownCloud’s Cron background-job mode. The second actually runs queued background jobs. ownCloud’s occ command documentation states that system:cron is intended for scheduled execution and that progress output should not be enabled in a non-interactive scheduler.

Common misunderstanding: “Cron mode” in ownCloud does not mean you must use the cron daemon specifically. It means ownCloud expects an external scheduler to invoke its background-job runner. A systemd timer can be that scheduler.

Azione: se il comando manuale fallisce, correggere prima quell'errore. Un timer si limiterà a ripetere lo stesso errore a intervalli regolari.

Passaggio 2: Trova i percorsi corretti di PHP e ownCloud

Alcune installazioni rendono occil programma eseguibile direttamente; altre sono più prevedibili se avviate tramite il binario PHP CLI. Verifica entrambe le opzioni:

command -v php
readlink -f /var/www/owncloud/occ
sudo -u www-data /usr/bin/php -f /var/www/owncloud/occ system:cron

La documentazione di ownCloud avverte esplicitamente che i processi pianificati devono trovare PHP e pertanto mostra i percorsi completi negli esempi di cron. Questo è altrettanto importante con systemd perché i servizi ricevono un ambiente controllato anziché l'ambiente shell interattivo dell'utente.

Azione: sostituire /usr/bin/php, /var/www/owncloud, e www-datanegli esempi rimanenti con i valori che hanno funzionato sul tuo host.

Passaggio 3: Creare un servizio systemd monouso

Crea /etc/systemd/system/owncloud-cron.service:

[Unit]
Description=Run ownCloud background jobs
After=network.target

[Service]
Type=oneshot
User=www-data
Group=www-data
WorkingDirectory=/var/www/owncloud
ExecStart=/usr/bin/php -f /var/www/owncloud/occ system:cron

Normalmente non è necessaria una [Install]sezione per il servizio perché viene attivato dal timer. Mantenere il servizio in questo modo Type=oneshotsemplifica anche l'interpretazione del suo ciclo di vita: si avvia, esegue il comando una volta, termina e torna inattivo.

Errore comune: un servizio oneshot inattivo non si interrompe automaticamente. Dopo un'esecuzione riuscita, un servizio oneshot RemainAfterExit=yesnormalmente diventa inattivo.

Azione: valutare il successo in base al codice di uscita e al registro degli eventi, non aspettandosi che il servizio rimanga "in esecuzione".

Passaggio 4: Creare il timer systemd

Crea /etc/systemd/system/owncloud-cron.timer:

[Unit]
Description=Run ownCloud background jobs every 15 minutes

[Timer]
OnCalendar=*:0/15
Persistent=true
Unit=owncloud-cron.service

[Install]
WantedBy=timers.target

La documentazione di ownCloud relativa a host-cron raccomanda una pianificazione di 15 minuti. Il timer sopra riportato segue tale cadenza. L' Persistent=trueutilizzo di un OnCalendartimer è utile perché systemd può attivare un evento del calendario mancato dopo che la macchina torna disponibile. Il comportamento esatto dipende comunque dalla versione di systemd e dalla durata del periodo di inattività della macchina.

Azione: se hai bisogno di un intervallo diverso, modificalo deliberatamente anziché copiare un valore da un altro server. Un'esecuzione più frequente può aumentare il carico in background; un'esecuzione meno frequente può ritardare le operazioni in coda.

Passaggio 5: ricarica systemd e abilita il timer

sudo systemctl daemon-reload
sudo systemctl enable --now owncloud-cron.timer
sudo systemctl status owncloud-cron.timer

daemon-reloadConsente a systemd di rileggere i file delle unità. enable --nowEntrambe le opzioni abilitano il timer per gli avvii futuri e lo avviano immediatamente.

Azione: se il timer non è attivo, verificare systemctl status owncloud-cron.timerprima di modificare nuovamente la configurazione di ownCloud.

Passaggio 6: Verificare le esecuzioni del timer successivo e precedente

systemctl list-timers owncloud-cron.timer
systemctl list-timers --all | grep owncloud-cron

list-timersè il modo più rapido per confermare che systemd ha pianificato una nuova attivazione e per vedere quando il timer è stato eseguito l'ultima volta. Questo distingue tra "il timer non è mai stato eseguito" e "il timer è stato eseguito ma ownCloud ha fallito all'interno del servizio".

Azione: se NEXT non è presente o il timer non è elencato, ricontrollare il nome del file del timer, [Install]la sezione e se l'unità è stata abilitata.

Passaggio 7: Controllare il registro di manutenzione, non solo il timer.

systemd registra l'output dei servizi nel journal a meno che non lo si reindirizzi esplicitamente altrove. La documentazione ufficiale di journalctl descrive come filtrare le voci del journal in base all'unità systemd.

sudo journalctl -u owncloud-cron.service --since today
sudo journalctl -u owncloud-cron.service -n 100 --no-pager

Un equivoco comune: "Il timer è attivo, quindi il cron di ownCloud funziona". Un timer attivo indica solo che lo scheduler è in attesa di essere eseguito. È comunque necessaria una corretta invocazione del servizio.

Azione: cerca errori PHP, messaggi di autorizzazione negata, file mancanti, errori del database o uno stato di uscita diverso da zero. Risolvi il primo errore concreto anziché riavviare ripetutamente il timer.

Passaggio 8: Avvia un'esecuzione su richiesta e verifica ownCloud

Non è necessario attendere 15 minuti per il test finale:

sudo systemctl start owncloud-cron.service
sudo systemctl status owncloud-cron.service
sudo -u www-data /usr/bin/php -f /var/www/owncloud/occ status

Dopo un'esecuzione oneshot riuscita, systemctl statusè possibile segnalare legittimamente il servizio come inattivo, mostrando anche status=0/SUCCESS. Il risultato importante è che il comando è stato completato con successo.

Azione: dopo che il test di servizio manuale ha esito positivo, attendere almeno un'attivazione del timer programmato e verificare che venga visualizzata una nuova voce di registro senza intervento manuale.

Se ancora non funziona: risolvi il problema per livello

Una nota su cron.php e le guide precedenti

Le istruzioni meno recenti di ownCloud spesso richiamano cron.phpdirettamente. La documentazione attuale di ownCloud raccomanda di utilizzare occ system:cron, e le note di rilascio di ownCloud spiegano la migrazione dal vecchio cron.phpapproccio diretto. Consultare le note di rilascio di ownCloud Server .

Azione: se hai ereditato una vecchia unità crontab o systemd che esegue cron.php, confrontala con la documentazione della versione di ownCloud installata prima di mantenerla.

Lista di controllo per la verifica finale

• ownCloud è configurato per i processi in background Cron.
• Il comando esatto occ system:cronviene eseguito correttamente con l'account del server web previsto.
• owncloud-cron.timerè abilitato e active (waiting).
• systemctl list-timersmostra sia l'attivazione successiva che quella precedente dopo che è trascorso un tempo sufficiente.
• journalctl -u owncloud-cron.servicemostra le esecuzioni programmate con successo.
• La configurazione non duplica i processi cron già forniti dall'immagine Docker ufficiale di ownCloud o da altri scheduler.

Quando tutti questi controlli vengono superati, avrete verificato ben più della semplice "esistenza di un timer": avrete dimostrato che systemd pianifica l'attività, avvia ownCloud con l'account corretto e completa con successo l'esecuzione dell'attività in background.