Vereinzelt extrem lange Laufzeit der cron.php (Syno,cli, 4h+)

🌐 Non-english support đŸ‡©đŸ‡Ș Deutsch (german)
, , , , ,
1

Moin,

  • Auf welcher Hardware? Synology DS420+

  • Betriebssystem DSM 7.2.1-69057 Update 3

  • Nextcloud Version: 28.0.3

  • PHP Version: PHP8.2 mit memcache.so und redis.so, configuriert ĂŒber die WebStation

  • Welche Datenbank? MariaDB

  • Apache version 2.4

  • NC lĂ€uft nativ

  • Bei was fĂŒr einer Aktion ist der Fehler aufgetreten?
    Über den Aufgabenplaner von DSM lĂ€uft alle 5 min dieser Befehl:

time sudo -u http php82 /volume2/web/nextcloud/cron.php

Das Ergebnis schickt mir der Aufgabenplaner via EMail.

In aller Regel habe ich so Laufzeiten um die 15sec, einzelne Ausreisser auch mal 30.

Und morgens so ab um zwei schickt er mir Mails mit:
Der Aufgabenplaner hat eine geplante Aufgabe ĂŒbersprungen, da sie bereits ausgefĂŒhrt wird.

Also mal die letzten beiden LĂ€ufe davor angeschaut:

Aufgabe: Nextcloud Cron
Start: Wed, 06 Mar 2024 02:00:01 +0100
Ende: Wed, 06 Mar 2024 02:04:35 +0100
Aktueller Status: 0 (Normal)
Standardausgabe/Fehler:
real 4m34.178s
user 0m11.650s
sys 0m0.679s

und hier der, der alles geblockt hat:
Aufgabe: Nextcloud Cron
Start: Wed, 06 Mar 2024 02:05:01 +0100
Ende: Wed, 06 Mar 2024 06:55:05 +0100
Aktueller Status: 0 (Normal)
Standardausgabe/Fehler:
real 290m4.232s
user 4m59.522s
sys 5m1.356s

Sprich, der lief 4h+.

Aus der config.php:
‘memcache.local’ => ‘\OC\Memcache\APCu’,

  • ‘memcache.distributed’ => ‘\OC\Memcache\Redis’,*
  • ‘memcache.locking’ => ‘\OC\Memcache\Redis’,*
  • ‘maintenance_window_start’ => 1,*

In der /usr/local/etc/php82/cli/php.ini findet sich:
max_execution_time = 240

Unter /usr/local/etc/php82/cli/conf.d liegt eine nextcloud.ini mit
extension = apcu.so
extension = redis.so

[core]
memory_limit = 2G
upload_max_filesize = 512M
post_max_size = 512M

[apc]
apc.shm_size = 512M
apc.enable_cli = 1

Diese wird auch geladen und berĂŒcksichtigt.

Ich kann via putty auf die NC/Syno zugreifen.

Welche Mittel habe ich, um rauszufinden, was die Laufzeit der cron.php so in die Höhe treibt? Wie schafft es das Script ĂŒber die max_execution_time = 240?

2

Eine geplante Aufgabe wurde ĂŒbersprungen, da sie bereits ausgefĂŒhrt wird

Diese Meldung hatte ich im vergangenen Jahr auch sehr oft und dabei lief der Cron bei mir allerdings nur bis zu 30 Minuten. Eine Ursache konnte ich dafĂŒr leider nicht genau ausmachen.

Da es ursprĂŒnglich sehr oft auch am Tage passierte, habe ich so wie Du ‘maintenance_window_start’ => 1, in die config.php eingefĂŒgt und es lief dann in der Nacht. Irgendwann im Oktober war der Spuk dann plötzlich vorbei.

Die Beschreibung von ‘maintenance_window_start’ sagt aus, dass es fĂŒr Befehle genutzt wird, welche nur einmal am Tag ausgefĂŒhrt werden. Daher habe ich vermutet, dass es sich um eine Indizierung handelt, welche speziell von der App “Memories” kommen könnte. Auch eine Verbindung mit externen Speichern hatte ich in Verdacht.

ErgÀnzung:
Ich konnte in meiner Tabelle “oc_jobs” noch den Job “OCA\SuspiciousLogin\BackgroundJob\TrainJobIpV6” ausmachen, welcher alle 24 Stunden lĂ€uft.

3

Moin.

Es gibt Aufgaben von Apps, welche nur einmal am Tag ausgefĂŒhrt werden. Hier gehört z.B. Memories und Recognize dazu.
Sollten diese Apps mal etwas wirklich lÀngeres zu tun bekommen, dann kann es schon mal sein, dass der Cron-Job lÀnger braucht.

Das ist von deinem System daher eine reine Sicherheitsmaßnahme, damit der Cron-Job nicht mehrmals parallel lĂ€uft.

Letztendlich ist es entscheidend was du fĂŒr Apps installiert hast.

4

Vielen Dank fĂŒr Eure Antworten.

Mir ist schon klar, das (gerade mit ‘maintenance_window_start’ =1) das bestimmte Aufgaben nur zu besonderen Zeiten ausgefĂŒhrt werden und dies erstmal grundsĂ€tzlich natĂŒrlich auch die Laufzeit der cron.php verlĂ€ngert.

Und auch das der nÀchste Job vom System nicht gestartet wird, wenn der alte noch lÀuft, ist grundsÀtzlich sinnvoll.

Doch normalerweise lasse ich den Aufgabenplaner nur dann Mails an mich senden, wenn auch wirklich ein Fehler auftritt. Das heisst, WENN ich eine Mail bekomme, ist echt was im Argen.

Da ist es natĂŒrlich doof, diese “Ich konnte grade nicht”-Mails zu bekommen.

Deshalb wollte ich dem System ein wenig genauer auf die Finger schauen, was es denn da so macht bei seiner cron.php. Und bei welchem Punkt der hohe Zeitbedarf entsteht.

Das Problem von aussen zu umkreisen und StĂŒck fĂŒr StĂŒck irgendwelche Apps zu deaktivieren, finde ich irgendwie “Von hinten ins Auge”. Allzumal die langen Laufzeiten nicht permanent (auch nicht zwingend tĂ€glich) auftreten. Da ist es dann schwer zu entscheiden, ob das Nichtauftreten der langen Laufzeit aufgrund der deaktivierten App oder einfach so erfolgte.

Na, vielleicht hat ja noch wer eine Idee, wie man der cron.php etwas von ihren Geheimnissen entlocken kann.

GrĂŒĂŸe, Orsa