Problembehebung: ownCloud Cron-Job läuft nicht – Einen zuverlässigen systemd-Timer einrichten

Sie öffnen die Admin-Oberfläche von ownCloud und stellen fest, dass Hintergrundprozesse in letzter Zeit nicht ausgeführt wurden oder dass Aufräumarbeiten, Aktivitäts-, externe Speicher- und andere in der Warteschlange befindliche Aufgaben verzögert erscheinen. Eine gängige Reaktion ist, die cron.phpCrontab-Einträge zu bearbeiten oder einen weiteren hinzuzufügen. Laut der aktuellen ownCloud Server-Dokumentation ist dies jedoch nicht der beste Ansatz: ownCloud empfiehlt den Cron-Hintergrundmodus und den occ system:cronentsprechenden Befehl. Auf einem Linux-Host kann anstelle der herkömmlichen Crontab ein systemd-Timer die Planungsebene bereitstellen.

Diese Anleitung konzentriert sich auf eine Paket- oder Bare-Metal-Installation, bei der ownCloud unter einem Pfad wie z. B. `/etc/ownCloud/docker-command` liegt /var/www/owncloud. Wenn Sie das offizielle Docker-Image von ownCloud verwenden, warten Sie, bevor Sie einen Host-Timer erstellen: ownCloud dokumentiert, dass das Image cron bereits intern konfiguriert, gesteuert durch Variablen wie `cron.command` OWNCLOUD_CROND_ENABLEDund `cron.command` OWNCLOUD_CROND_SCHEDULE. Weitere Informationen finden Sie in der aktuellen Dokumentation zu den Hintergrundjobs von ownCloud .

Was ist verifiziert, was hängt von Ihrem Server ab und was muss noch überprüft werden?

• Bestätigt: ownCloud empfiehlt Cron anstelle von AJAX für die zuverlässige Ausführung von Hintergrundprozessen und dokumentiert dies occ system:cronals Befehl zum Ausführen von in die Warteschlange gestellten Hintergrundaufgaben.
• Hängt von Ihrer Installation ab: dem ownCloud-Verzeichnis, der PHP-Binärdatei, dem Webserver-Konto, der PHP-Umgebung und davon, ob Sie eine Paketinstallation, einen Container, eine Appliance oder eine benutzerdefinierte Bereitstellung durchführen.
• Aus einer allgemeinen Anleitung lässt sich nicht ermitteln, warum Ihr aktueller Job fehlgeschlagen ist. Es könnte ein Problem mit dem Scheduler sein, aber auch Berechtigungen, ein falscher Pfad, eine abweichende PHP-CLI-Konfiguration, Datenbankverbindungsprobleme, Dateisperren oder ein Fehler in einem anwendungsseitigen Hintergrundprozess können die Ursache sein.

Maßnahme: Erstellen Sie keinen Timer, bis der entsprechende ownCloud-Befehl manuell unter demselben Konto funktioniert, das der Timer verwenden soll.

Schritt 1: Cron-Modus bestätigen und ownCloud manuell testen

Bei einer typischen Apache/Debian-Installation ist der Webbenutzer `webuser` www-data. Ersetzen Sie sowohl den Benutzer als auch den Pfad, falls Ihre Umgebung abweicht.

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

Der erste Befehl aktiviert den Cron-Hintergrundjob-Modus von ownCloud. Der zweite Befehl führt die in der Warteschlange befindlichen Hintergrundjobs aus. Laut der Dokumentation des ownCloud-Befehls `occ` ist dieser system:cronfür die geplante Ausführung vorgesehen, und die Fortschrittsanzeige sollte in einem nicht-interaktiven Scheduler deaktiviert werden.

Häufiges Missverständnis: Der „Cron-Modus“ in ownCloud bedeutet nicht, dass Sie den cronDaemon zwingend verwenden müssen. Er bedeutet, dass ownCloud einen externen Scheduler erwartet, der seinen Hintergrundprozess ausführt. Ein systemd-Timer kann dieser Scheduler sein.

Vorgehen: Falls der manuelle Befehl fehlschlägt, beheben Sie diesen Fehler zuerst. Ein Timer wiederholt denselben Fehler nur nach einem festgelegten Zeitplan.

Schritt 2: Finden Sie die korrekten PHP- und ownCloud-Pfade

Bei manchen Installationen ist occdie Datei direkt ausführbar; bei anderen ist das Verhalten besser vorhersehbar, wenn sie mit der PHP-CLI-Binärdatei aufgerufen werden. Prüfen Sie beides:

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

Die ownCloud-Dokumentation weist ausdrücklich darauf hin, dass geplante Jobs PHP benötigen und zeigt daher in Cron-Beispielen die vollständigen Pfade an. Dies ist auch unter systemd relevant, da Dienste eine kontrollierte Umgebung anstelle Ihrer interaktiven Shell-Umgebung nutzen.

Maßnahme: Ersetzen Sie /usr/bin/php, /var/www/owncloud, und www-datain den verbleibenden Beispielen durch die Werte, die auf Ihrem Host funktioniert haben.

Schritt 3: Erstellen eines einmaligen systemd-Dienstes

Erstellen /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

Normalerweise benötigen Sie keinen separaten [Install]Abschnitt für den Dienst, da dieser vom Timer aktiviert wird. Die Verwendung eines solchen Abschnitts Type=oneshoterleichtert zudem die Nachvollziehbarkeit seines Lebenszyklus: Er startet, führt den Befehl einmal aus, beendet sich und wird anschließend wieder inaktiv.

Häufiges Missverständnis: Ein inaktiver Einmal-Dienst wird nicht automatisch deaktiviert. Nach erfolgreichem Durchlauf RemainAfterExit=yeswird ein Einmal-Dienst normalerweise inaktiv.

Vorgehen: Beurteilen Sie den Erfolg anhand des Exit-Codes und des Protokolls, nicht anhand der Erwartung, dass dieser Dienst weiterhin „läuft“.

Schritt 4: Erstellen Sie den systemd-Timer

Erstellen /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

Die Dokumentation zu host-cron von ownCloud empfiehlt einen 15-Minuten-Zyklus. Der oben genannte Timer folgt diesem Rhythmus. Persistent=trueDie Verwendung eines OnCalendarTimers ist nützlich, da systemd eine verpasste Kalenderaktivierung auslösen kann, sobald der Rechner wieder verfügbar ist. Das genaue Verhalten hängt weiterhin von der systemd-Version und der Dauer des Ausfalls ab.

Empfehlung: Falls Sie ein anderes Intervall benötigen, ändern Sie es bewusst, anstatt einen Wert von einem anderen Server zu kopieren. Häufigere Ausführung kann die Hintergrundlast erhöhen; seltenere Ausführung kann die in der Warteschlange befindlichen Aufgaben verzögern.

Schritt 5: systemd neu laden und den Timer aktivieren

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

daemon-reloadVeranlasst dazu, dass systemd die Unit-Dateien neu einliest. enable --nowDies aktiviert den Timer sowohl für zukünftige Systemstarts als auch startet ihn sofort.

Maßnahme: Falls der Timer nicht aktiv ist, überprüfen Sie systemctl status owncloud-cron.timerdie ownCloud-Konfiguration, bevor Sie sie erneut ändern.

Schritt 6: Überprüfen Sie die nächsten und vorherigen Timerläufe.

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

list-timersDies ist der schnellste Weg, um zu bestätigen, dass systemd eine nächste Aktivierung geplant hat und um zu sehen, wann der Timer zuletzt ausgelöst wurde. Dadurch lässt sich unterscheiden, ob der Timer nicht ausgeführt wurde oder ob er zwar ausgeführt wurde, ownCloud aber innerhalb des Dienstes einen Fehler hatte.

Maßnahme: Falls NEXT fehlt oder der Timer nicht aufgeführt ist, überprüfen Sie den Dateinamen des Timers, [Install]den Abschnitt und ob die Einheit aktiviert wurde.

Schritt 7: Überprüfen Sie das Serviceprotokoll, nicht nur den Timer.

systemd protokolliert die Serviceausgabe im Journal, sofern diese nicht explizit umgeleitet wird. Die offizielle Dokumentation zu journalctl beschreibt das Filtern von Journaleinträgen nach systemd-Unit.

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

Häufiges Missverständnis: „Der Timer ist aktiv, also funktioniert ownCloud Cron.“ Ein aktiver Timer beweist lediglich, dass der Scheduler auf seine Ausführung wartet. Ein erfolgreicher Dienstaufruf ist weiterhin erforderlich.

Maßnahme: Suchen Sie nach PHP-Fehlern, Zugriffsverweigerungsmeldungen, fehlenden Dateien, Datenbankfehlern oder einem Exit-Status ungleich null. Beheben Sie den ersten konkreten Fehler, anstatt den Timer wiederholt neu zu starten.

Schritt 8: Einen Lauf bei Bedarf auslösen und ownCloud überprüfen.

Sie müssen nicht 15 Minuten auf den Abschlusstest warten:

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

Nach einem erfolgreichen einmaligen Durchlauf systemctl statuskann der Dienst berechtigterweise als inaktiv gemeldet werden, wobei gleichzeitig angezeigt wird, status=0/SUCCESSdass der Befehl erfolgreich ausgeführt wurde.

Vorgehen: Nach erfolgreichem manuellem Servicetest warten Sie auf mindestens eine geplante Timer-Aktivierung und vergewissern Sie sich, dass ohne manuelles Eingreifen ein neuer Journaleintrag erscheint.

Falls es immer noch nicht läuft: Fehlerbehebung auf Ebene der einzelnen Ebenen.

Ein Hinweis zu cron.php und älteren Anleitungen

Ältere ownCloud-Anleitungen verwenden oft einen cron.phpdirekten Aufruf. Die aktuelle ownCloud-Dokumentation empfiehlt die Verwendung von ` occ system:crononCloud Server`, und die ownCloud-Versionshinweise erläutern die Umstellung von diesem älteren cron.phpAnsatz. Siehe die Versionshinweise zum ownCloud Server .

Maßnahme: Falls Sie eine alte Crontab- oder Systemd-Unit übernommen haben, die ausgeführt wird cron.php, vergleichen Sie diese mit der Dokumentation Ihrer installierten ownCloud-Version, bevor Sie sie beibehalten.

Checkliste zur abschließenden Überprüfung

• ownCloud ist für Cron-Hintergrundjobs konfiguriert.
• Der occ system:cronBefehl wird unter dem vorgesehenen Webserver-Konto erfolgreich ausgeführt.
• owncloud-cron.timerist aktiviert und active (waiting).
• systemctl list-timersZeigt sowohl die nächste als auch die vorherige Aktivierung an, nachdem genügend Zeit vergangen ist.
• journalctl -u owncloud-cron.serviceZeigt erfolgreiche geplante Ausführungen an.
• Die Einrichtung dupliziert keine Cron-Jobs, die bereits im offiziellen ownCloud Docker-Image oder einem anderen Scheduler enthalten sind.

Wenn all diese Prüfungen erfolgreich sind, haben Sie mehr als nur die Existenz eines Timers nachgewiesen: Sie haben gezeigt, dass systemd den Job plant, ownCloud unter dem richtigen Konto aufruft und den eigentlichen Hintergrundjob-Runner erfolgreich abschließt.