Fehler nach Update auf 4.9.5

[landzone]

Hallo,

nach dem Update auf 4.9.5 funktioniert das Autobackup nicht mehr und ich erhalte folgende Fehlermeldung im Log:

request.CRITICAL: Uncaught PHP Exception Symfony\Component\HttpClient\Exception\TransportException: "Idle timeout reached for "https://www.meine-domain.de/BackupDB/autobackup"." at /homepages/.../vendor/symfony/http-client/Chunk/ErrorChunk.php line 64 {"exception":"[object] (Symfony\\Component\\HttpClient\\Exception\\TransportException(code: 0): Idle timeout reached for \"https://www.meine-domain.de/BackupDB/autobackup\". at /homepages/.../vendor/symfony/http-client/Chunk/ErrorChunk.php:64)"} []

Interessanterweise erhalte ich die E-Mail über das erfolgte Backup mehrfach, obwohl gar kein Backup stattgefunden hat. Eingerichtet ist das Ganze über den Scheduler (cron-bundle)
Kann mir da wer weiterhelfen?
Danke und viele Grüße
Silvia

[do_while]

den Fehler kenne ich bisher nicht.
Ich kann aber erst nächste Woche nachsehen woran es liegen könnte.

Wie rufst Du das Autobackup auf?
also was hast Du in der Cron-Erweiterung drin stehen?

[BugBuster]

Funktioniert das Backup wenn du es manuell startest?

Welche Version von der Cron Erweiterung ist installiert?

[landzone]

@do_while
Der Aufruf lautet:

https://www.meine-domain.de/BackupDB/autobackup

@BugBuster
Auch ein manueller Start funktioniert nicht und bringt den gleichen Fehler.
Cron-Bundle ist in Version 1.4.2 installiert, BackupDB in Version 1.4.1.

Danke für eure Hilfe!

[do_while]

Hallo landzone,

bin gerade aus dem Urlaub zurück.
In meiner 4.9.5 funktioniert der AutoBackup und erzeugt auch ein ZIP mit den gewünschten Inhalten.

Nun steht ja in der Meldung etwas von einem Timeout, obwohl mir der Wortlaut nicht so bekannt vorkommt.
Vielleicht hast Du so viele Daten, dass die PHP-Laufzeit nicht ausreicht für eine Komplett-Sicherung

Kann es sein, dass Du alle Tabellen sicherst, auch die nicht essentiell wichtigen?
Ich habe bei mir immer die tl_search, tl_search_index, tl_session, tl_version, tl_log auf der Blacklist um die Daten zu reduzieren.

[landzone]

@do_while
Ich habe in den Einstellungen folgende Tabellen ausgeschlossen: tl_lock, tl_log, tl_search, tl_search_index, tl_session, tl_undo, tl_version
Das kann also nicht die Ursache sein.

Ich habe beide Erweiterungen nun nochmal deinstalliert und neu installiert, keine Änderung.

Dann habe ich mit den Einstellungen gespielt und folgendes festgestellt:
Wenn ich die Checkbox "Backup mit Restoreinfos komprimieren" deaktiviere, kommt die Fehlermeldung nicht.

Das Backup wird aber in beiden Fällen (mit und ohne Komprimierung) trotzdem durchgeführt, die Dateien werden generiert.

Der Unterschied ist, dass im System-Log bei deaktivierter Chekbox (also ohne Komprimierung) die Meldung "Manually scheduler job complete" erscheint, bei aktivierter Komprimierung jedoch nicht.

Hast du eine Erklärung dafür? Ich hoffe, ich hab alles verständlich dargelegt.

Danke und viele Grüße
Silvia

[Spooky]

Backups würde ich generell nicht über einen HTTP Request ausführen lassen. Da läufst du immer in Gefahr an die max_execution_time oder das memory_limit zu kommen.

[landzone]

@Spooky
Heißt das, du würdest die Extension BackupDB zusammen mit dem Cron gar nicht einsetzen?
Was wäre deine Lösung innerhalb von Contao dafür?

[Spooky]

Wenn die Extension das Backup über einen Cron ausführt, dann solltest du den Cron auch für die Kommandozeile konfigurieren: https://docs.contao.org/manual/de/sy...-einstellungen

In der Entwickler Doku ist das ein wenig besser beschrieben aktuell: https://docs.contao.org/dev/framewor.../#command-line

[Spooky]

Was wäre deine Lösung innerhalb von Contao dafür?

Backups sollten vom System gemacht werden, nicht von der Applikation .

[BugBuster]

Jetzt muss ich doch nochmal nachfragen. Als du es manuell gestartet hast, wie hast du das getan?
Direkt in BackupDB oder hast du "nur" den Cron Job manuell gestartet?

Sinn war herauszufinden, ob es an BackupDB oder an der Cron Erweiterung liegt. Da in letzteres einige Änderungen in der letzten Zeit gab, ist es durchaus möglich, dass es da Probleme geben könnte.

[landzone]

@BugBuster
Das BackupDB selbst kann ich manuell starten und es läuft durch.

Den Cronjob kann ich manuell starten und der bringt den gleichen Fehler wie das automat. Starten. Sorry, da hab ich auch etwas unklar geantwortet.
Also liegt es wohl an der Cron-Erweiterung. Sollte ich da nochmal im anderen Forum fragen?

Viele Grüße
Silvia

[BugBuster]

Also liegt es wohl an der Cron-Erweiterung. Sollte ich da nochmal im anderen Forum fragen?

Nicht nötig, ich lese ja hier mit.

Nachtrag: notiert. https://github.com/BugBuster1701/con...ndle/issues/39

[BugBuster]

Derzeit "wartet" der http-client den Cron benutzt 3 Sekunden. Dauert der Job länger wird abgebrochen.
Das widerspricht der Controller Einstellung 5 Sekunden zu warten, das ist also ein Bug von mir.

Frage wäre, würden 5 Sekunden reichen? Längere Jobs sollten dann wirklich von extern gestartet werden. Vom Backend ausgelöst könnte man vielleicht noch länger warten, aber im Frontend würde ich das nicht wollen, auch wenn es per XMLHttpRequest ausgelöst wird und der Nutzer davon also nichts merkt.

Warum die TransportException nicht abgefangen wird verstehe ich grad nicht, mein Aufruf ist in try catch gekapselt. Würde ja bedeuten, das der Symfony HTTP Client die Exception selbst fängt und den Request abbricht. Muss ich testen.

[do_while]

@BugBuster:
Für ein Backup sind natürlich 5 Sekunden auch nicht viel.

Idee: kannst Du den Timeout von dem Zeitintervall abhängig machen?
Ein Backup macht man ggf. 1x pro Tag (Termin nachts), das trifft zwar dann auch einen Aufruf, der warten muss, aber häufige Jobs in der Hauptgeschäftszeit müßten dann schneller fertig werden.

[BugBuster]

Ich hatte schon die Idee, das man je Job die maximale Zeit selber angeben kann, falls es länger sein muss.

[Spooky]

Wie gesagt sollte aber ein Backup sowieso keinesfalls innerhalb eines HTTP Requests durchgeführt werden.

[do_while]

Du hast ja Recht Spooky,

aber in sehr primitiven/preiswerten Hostingpaketen ist das teilweise die einzige Möglichkeit der Automatisierung.
Selbst sichere ich die Installationen auch per Cronjob und mysqldump für die Datenbank bzw. tar für den Webspace (All-Inkl).

[BugBuster]

Cron Bundle 1.4.5 ist nun online, kleiner Hotfix.

• maximale Ausführungszeit von 3 auf 5 Sekunden erhöht
• Abfangen der Exception bei Überschreitung
• Meldung in Systemlog bei Fehler

[landzone]

@BugBuster
Bei mir scheint die Ausführungszeit noch nicht auszureichen. Erst nach mehrmaligem Start und Fehlermeldung im Systemlog kommt irgendwann die Erfolgsmeldung. Im Fehlerfall wird jedesmal trotzdem die E-Mail generiert. Hier ein Beispiel, die Anzahl der Versuche variiert...
backup.jpg