Das willst Du auch nicht... / Nachfrage

[Rolf B]

Hallo Jörg,

Anruf beim Support bracjte die Erkentniss, dass (vermutlich) Scripte, die über cron angestoßen werden, dem script-time-limit nicht unterliegen, aber "sollte/könnte/würde" bringt auch nicht wirklich was. Wir leben nicht im Konjunktiv

Es gibt zwei potenzielle Script-Execution Killer:

1. PHP, mit max_execution_time in der php.ini. Diesen Wert kannst Du je nach PHP Einrichtung mit set_time_limit überschreiben. Die PHP Doku sagt: Wird PHP von der Kommandozeile gestartet, ist max_execution_time=0 (also unbegrenzt)

guckst du

2. Die Ausführungsumgebung. Für einen Webrequest ist das der Webserver (apache), für einen cron-Job ist es was anderes. Ein Timeout Wert im Apache gilt deshalb für einen cron Job nicht. Und wenn Du im cron Job PHP aus einem Script heraus startest, ist das ein Kommandozeilenaufruf, der max_execution_time aushebeln dürfte, so dass nur ein in cron gesetztes Ausführungslimit greifen sollte.

Ein kompetenter Support sollte Dir das ohne Konjunktive und mit exakten Zahlen erklären können.

Ansonsten hilft nur probieren, mach ein Script, das in einer Logdatei zu Beginn den Startzeitpunkt und die gefundenen DBs einträgt und nach jedem Dump den den gedumpten DB-Namen und den Fertigstellungszeitpunkt loggt. Dann siehst Du ja, wie lange er braucht und ob er abbricht.

Dein Self-Restart ergibt dann und nur dann einen Sinn, wenn der Dump jeder einzelnen Datenbank innerhalb der Script-Ausführungszeit liegt, aber die Summe der Ausführungszeiten zu groß wird. Ein cron Job ist für Backups eh besser, würde ich sagen, weil der vom Server aus zeitgesteuert ist.

Rolf