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.

Acțiune: dacă comanda manuală eșuează, remediați mai întâi eroarea respectivă. Un cronometru va repeta aceeași eroare doar într-un anumit interval orar.

Pasul 2: Găsiți căile corecte PHP și ownCloud

Unele instalări fac occexecutabil direct; altele sunt mai previzibile atunci când sunt invocate cu binarul CLI PHP. Confirmați ambele:

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

Documentația ownCloud avertizează explicit că joburile programate trebuie să găsească PHP și, prin urmare, afișează căile complete în exemplele cron. Acest lucru contează la fel de mult și în systemd, deoarece serviciile primesc un mediu controlat, mai degrabă decât mediul interactiv shell.

Acțiune: înlocuiți /usr/bin/php, /var/www/owncloud, și www-dataîn exemplele rămase cu valorile care au funcționat pe gazda dvs.

Pasul 3: Creați un serviciu systemd unic

Creați /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

În mod normal, nu aveți nevoie de o [Install]secțiune pentru serviciu, deoarece cronometrul îl activează. Păstrarea serviciului ca Type=oneshotaces face, de asemenea, ușor de interpretat ciclul său de viață: pornește, execută comanda o dată, se închide și devine din nou inactiv.

Neînțelegere frecventă: un serviciu one-shot inactiv nu este automat defect. După o rulare reușită, un serviciu one-shot fără acest serviciu RemainAfterExit=yesdevine în mod normal inactiv.

Acțiune: judecați succesul după codul de ieșire și jurnal, nu așteptându-vă ca acest serviciu să rămână „în funcțiune”.

Pasul 4: Creați cronometrul systemd

Creați /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

Documentația host-cron a ownCloud recomandă un program de 15 minute. Cronometrul de mai sus respectă această cadență. Persistent=trueeste util cu un OnCalendarcronometru deoarece systemd poate declanșa o activare a calendarului ratată după ce mașina devine din nou disponibilă. Comportamentul exact depinde în continuare de versiunea systemd și de cât timp mașina a fost nefuncțională.

Acțiune: dacă aveți nevoie intenționat de un interval diferit, modificați-l în mod deliberat, în loc să copiați o valoare de pe un alt server. Execuția mai frecventă poate crește încărcarea în fundal; execuția mai puțin frecventă poate întârzia lucrările din coadă.

Pasul 5: Reîncărcați systemd și activați cronometrul

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

daemon-reloadface ca systemd să recitească fișierele unității. enable --nowactivează cronometrul pentru pornirile viitoare și îl pornește imediat.

Acțiune: dacă temporizatorul nu este activ, verificați systemctl status owncloud-cron.timerînainte de a modifica din nou configurația ownCloud.

Pasul 6: Verificați următoarea și precedenta rulare a cronometrului

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

list-timerseste cea mai rapidă metodă de a confirma că systemd a programat o următoare activare și de a vedea când s-a declanșat ultima dată cronometrul. Aceasta face diferența între „cronometrul nu a funcționat niciodată” și „cronometrul a funcționat, dar ownCloud a eșuat în cadrul serviciului”.

Acțiune: dacă lipsește NEXT sau cronometrul nu este listat, verificați din nou numele fișierului cronometrului, [Install]secțiunea și dacă unitatea a fost activată.

Pasul 7: Verificați jurnalul de service, nu doar cronometrul

systemd înregistrează ieșirea serviciului în jurnal, cu excepția cazului în care o redirecționați în mod deliberat în altă parte. Documentația oficială journalctl descrie filtrarea intrărilor din jurnal după unitatea systemd.

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

Neînțelegere frecventă: „Cronometrul este activ, deci cronul ownCloud funcționează.” Un cronometru activ dovedește doar că planificatorul așteaptă să se declanșeze. Totuși, este nevoie de o invocare reușită a serviciului.

Acțiune: căutați erori PHP, mesaje cu permisiune refuzată, fișiere lipsă, erori în baza de date sau o stare de ieșire diferită de zero. Remediați prima eroare concretă în loc să reporniți cronometrul în mod repetat.

Pasul 8: Declanșați o rulare la cerere și verificați ownCloud

Nu trebuie să așteptați 15 minute pentru un test final:

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

După o rulare cu succes a unei singure comenzi, systemctl statusse poate raporta în mod legitim serviciul ca inactiv, afișând în același timp status=0/SUCCESS. Rezultatul important este că comanda s-a finalizat cu succes.

Acțiune: după ce testul de service manual are succes, așteptați cel puțin o activare programată a temporizatorului și confirmați că apare o nouă intrare în jurnal fără intervenție manuală.

Dacă tot nu rulează: depanați pe straturi

O notă despre cron.php și ghidurile mai vechi

Instrucțiunile ownCloud mai vechi sunt adesea invocate cron.phpdirect. Documentația actuală ownCloud recomandă occ system:cron, iar notele de lansare ownCloud explică migrarea de la cron.phpabordarea directă mai veche. Consultați notele de lansare ownCloud Server .

Acțiune: dacă ați moștenit o unitate crontab sau systemd veche care rulează cron.php, comparați-o cu documentația pentru versiunea ownCloud instalată înainte de a o păstra.

Lista de verificare finală

• ownCloud este configurat pentru joburi Cron în fundal.
• Comanda exactă occ system:cronreușește sub contul de server web dorit.
• owncloud-cron.timereste activat și active (waiting).
• systemctl list-timersarată atât o activare următoare, cât și una anterioară după ce a trecut suficient timp.
• journalctl -u owncloud-cron.serviceafișează execuțiile programate cu succes.
• Configurarea nu duplică cron-ul deja furnizat de imaginea oficială ownCloud Docker sau de un alt planificator.

Când toate aceste verificări trec cu succes, ați verificat mai mult decât „existența unui cronometru”: ați demonstrat că systemd programează jobul, invocă ownCloud în contul corect și finalizează cu succes rularea jobului în fundal.