Webfrontend wird nach "configdb Backup" nicht mehr dargestellt

[Klaus Rubik]

Hallo Rudi,

seit ca. 13.05. wird nach einem configdb backup das Webfrontend von FHEM nicht mehr dargestellt. In Firefox kommt die Meldung:

Code Auswählen Erweitern

Fehler: Verbindung unterbrochen

Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.

    Die Website könnte vorübergehend nicht erreichbar sein, versuchen Sie es bitte später nochmals.
    Wenn Sie auch keine andere Website aufrufen können, überprüfen Sie bitte die Netzwerk-/Internetverbindung.
    Wenn Ihr Computer oder Netzwerk von einer Firewall oder einem Proxy geschützt wird, stellen Sie bitte sicher, dass Firefox auf das Internet zugreifen darf.

Bei Safari bleibt der Bildschirm weiß. Betateilchen meinte, ich sollte dich mal darauf ansprechen, da er hier auf ein Fronten-Problem tippt. Siehe hierzu auch http://forum.fhem.de/index.php/topic,23628.0.html

Danke
Klaus

[betateilchen]

Hier noch mein Senf zur Wurst:

Vermutung 1: Das Problem hängt mit Befehlen zusammen, deren Ausführung lange dauert.
Vermutung 2: Irgendwas führt dann dazu, dass der im Frontend eingegebene Befehl noch einmal zur Ausführung gebracht wird und deshalb das backup zweimal hintereinander läuft.

Die doppelte Ausführung des Backups tritt nur bei Aufruf im Frontend auf. Startet man das backup über telnet, wird es genau einmal ausgeführt.

[rudolfkoenig]

@betateilchen: waere es nicht sinnvoll, das Backup im Hintergrund zu machen, genau wie update das macht?
@Klaus: wie lange dauert denn dein backup?

[betateilchen]

@Rudi: hättest Du das backup nicht aus mir bis heute unerfindlichen und völlig unverständlichen Gründen nicht in 98_backup.pm für alle configDB-Benutzer generell verboten, hätten wir überhaupt kein Problem und es würde einfach funktionieren wie immer. Mein Backup macht inhaltlich exakt das gleiche wie Deines. Ich habe den Code für das Lesen der Verzeichnisse und das tar 1:1 kopiert.

Es würde viel mehr Sinn machen, eine vorhandene und funktionierende Lösung verwenden zu dürfen, anstatt alles zweimal programmieren zu müssen.

Das Backup bei Klaus dauert ca 75 Sekunden.

[Klaus Rubik]

@Klaus: wie lange dauert denn dein backup?

Hallo Rudi,

letzter Backup laut Logfile 1:26 Minuten:

Code Auswählen Erweitern

2014.05.16 07:35:29 2: Backup with command: tar -cf - ./99_dial.sh ./background.sh ./CHANGED ./configDB.conf ./configDB.pm ./contrib ./db.conf ./display-fhem-status.sh ./docs ./FHEM ./fhem.cfg ./fhem.cfg_ori ./fhem.pl ./fhem.png ./layout.txt ./log ./Poolsteuerung.cfg ./smaspot ./SMAspot.cfg ./unused ./wettersensor.cfg ./www |gzip > /backups/FHEM01/fhem/backups/FHEM-20140516_073529.tar.gz
2014.05.16 07:36:55 1: backup done: FHEM-20140516_073529.tar.gz (34397169 Bytes)


Gruß Klaus

[rudolfkoenig]

@betateilchen: ich glaube das Wort "unerfindlich" ist nicht richtig, "unverstaendlich" waere besser.
Ich habe es damit begruendet, dass ich kein backup Befehl zulassen will, der die Konfiguration nicht sichert.
Und das Backup ist "meins" in dem Sinn, dass ich es komissarisch betreue.
Tritt das Problem bei dir auch auf?

@Klaus: ist das Problem Firefox spezifisch?

[Klaus Rubik]

@Klaus: ist das Problem Firefox spezifisch?

nein, dass das Frontend nicht geladen wird, tritt auch bei Safari auf MAC und und bei Chrome auf Windows auch. Dort wurde eben auch der Backup gerade wieder 2 mal nacheinander ausgführt. Muss mal suchen, wie man dort den Cache löscht.

Nachtrag, Chrome ist dabei etwas mitteilsamer:

Code Auswählen Erweitern

Die Webseite kann nicht geladen werden, da der Server keine Daten gesendet hat.
Laden Sie die Webseite erneut.
Klicken Sie auf die Schaltfläche zum erneuten Laden, um die für das Laden der Seite erforderlichen Daten erneut zu senden.
Fehlercode: ERR_EMPTY_RESPONSE

Nachtrag 2: trotz löschen des Cache wurde im Chromebrowser das Backup wieder 2 x ausgeführt:

Code Auswählen Erweitern

2014.05.16 09:36:57 2: Backup with command: tar -cf - ./99_dial.sh ./background.sh ./CHANGED ./configDB.conf ./configDB.pm ./contrib ./db.conf ./display-fhem-status.sh ./docs ./FHEM ./fhem.cfg ./fhem.cfg_ori ./fhem.pl ./fhem.png ./FrameRSS.jpg ./layout.txt ./log ./Poolsteuerung.cfg ./smaspot ./SMAspot.cfg ./unused ./wettersensor.cfg ./www |gzip > /backups/FHEM01/fhem/backups/FHEM-20140516_093657.tar.gz
2014.05.16 09:37:59 1: backup done: FHEM-20140516_093657.tar.gz (34417829 Bytes)
2014.05.16 09:38:04 2: Backup with command: tar -cf - ./99_dial.sh ./background.sh ./CHANGED ./configDB.conf ./configDB.pm ./contrib ./db.conf ./display-fhem-status.sh ./docs ./FHEM ./fhem.cfg ./fhem.cfg_ori ./fhem.pl ./fhem.png ./FrameRSS.jpg ./layout.txt ./log ./Poolsteuerung.cfg ./smaspot ./SMAspot.cfg ./unused ./wettersensor.cfg ./www |gzip > /backups/FHEM01/fhem/backups/FHEM-20140516_093804.tar.gz
2014.05.16 09:39:17 1: backup done: FHEM-20140516_093804.tar.gz (34417829 Bytes)
2

Gruß

Klaus

[betateilchen]

Ich habe es damit begruendet, dass ich kein backup Befehl zulassen will, der die Konfiguration nicht sichert.
Und das Backup ist "meins" in dem Sinn, dass ich es komissarisch betreue.

Rudi, es geht nicht darum, ob es Deins ist oder nicht. Ich hatte Dich als Maintainer des Moduls damals lediglich darum gebeten, eine Fehlermeldung zu fixen, die bei configDB keinen Sinn macht. Mehr nicht. Und noch: configDB kann mit einer leeren Konfiguration starten, deshalb ist Dein Argument "kein backup der die Konfiguration nicht sichert" für mich keine Begründung.

Es wäre schön, wenn Du das nochmal überdenken würdest und die damals vorgeschlagene Änderung nur in Bezug auf die Fehlermeldung umsetzen könntest. Dann hätten wir bei update und backup genau die gleiche Transparenz für die configDB-Anwender, die wir auch sonst an allen Stellen geschaffen haben und alles wäre gut. Und auch das Problem von Klaus wäre damit sofort gelöst.

[betateilchen]

@betateilchen:
Tritt das Problem bei dir auch auf?

Bei mir gibt es keine Backups, die so lange dauern, deshalb konnte ich das Problem bei mir noch nicht reproduzieren.

[rudolfkoenig]

Es wäre schön, wenn Du das nochmal überdenken würdest

Ich habe nachgedacht, und bin der Ansicht, dass wenn aus der Backup-Datei die alte Konfiguration nicht hergestellt werden kann, dann ist das kein backup.

@Klaus: kannst Du bitte das verbose der FHEMWEB Instanz auf 4 setzen (attr WEB verbose 4), und das Befehl erneut ausfuehren? Danach interessiert mich, was im FHEM Log steht.

[betateilchen]

Ich habe nachgedacht, und bin der Ansicht, dass wenn aus der Backup-Datei die alte Konfiguration nicht hergestellt werden kann, dann ist das kein backup.

Ich halte diese Ansicht nach wie vor für nicht richtig. configDB hat im Gegensatz zu fhem.cfg den entscheidenden Unterschied, dass fhem selbst ohne eine gesicherte Konfiguration wieder lauffähig aus der Sicherung wiederhergestellt werden kann. Eine fhem-Installation besteht nicht nur aus dem Inhalt der fhem.cfg sonden beinhaltet ggf auch viele vom Benutzer selbst angelegte Dateien, die für fhem benötigt werden (floorplan, eigene css usw). Gerade diese Dateien begründen die viel größeren Probleme, wenn sie für eine Wiederherstellung nicht zur Verfügung stehen. Und genau diese Dateien werden mit dem regulären Backup mitgesichert. Ich verstehe nach wie vor nicht, warum Du den Anwendern der configDB diese problemlos funktionierende Möglichkeit der Datensicherung so vehement verweigerst. Der Inhalt der configDB selbst ist nur ein kleiner Puzzlestein im gesamten Backup-Mosaik. Aber wegen eines fehlenden Puzzlesteins ein Mosaik zu verwerfen, ist unsinnig. Es bleibt ein Mosaik, das eventuell einen kleinen Schönheitsfehler hat. Wegen einem Sprung in einer Fliese in Deinem Badezimmer würdest Du doch wahrscheinlich auch nicht das gesamte Badezimmer neu kacheln oder das Badezimmer nicht mehr benutzen.

[svenson08]

Bitte mal für mich als Erklärung wie das gemeint ist das aus einem Backup der configdb die alte Konfiguration nicht wieder hergestellt werden kann? Sorry ich versteh das so nicht - Rudi, kannst du mir das etwas Abflüssen (rein zum Verständnis)
Ich dachte ein Backup der dB hat alle configs inne. Daher dachte ich bisher das zu dem bisherigen Backup "nur" das Backup der dB angehängt werden muss.

[rudolfkoenig]

Ich bin der Ansicht, dass wenn man "backup" ausfuehrt, und das Ergebnis sichert, man alles zum Restaurieren haben sollte, ohne ene zusaetzliche Sicherung der Datenbank durchzufuehren. betateilchen ist der Ansicht, dass bei einer FHEM Installation mit Datenbank die Sicherung aus zwei Teilen besteht: 1. FHEM-Backup, 2. DB-Backup.

[betateilchen]

betateilchen ist der Ansicht, dass bei einer FHEM Installation mit Datenbank die Sicherung aus zwei Teilen besteht: 1. FHEM-Backup, 2. DB-Backup.

Was Rudi hier behauptet, ist definitiv NICHT meine Ansicht. Und genau diesen Trugschluss versuche ich ihm seit Wochen - leider erfolglos - darzulegen.

[Klaus Rubik]

Hallo Ihr 2,
wäre schön, wenn Ihr 2 Euch mal auf einen Kompromiss einigen könntet. Ich denke, Ihr habt beide teilweise Recht. Wie wäre es denn, wenn man sich auf Rudi's backup einigt, jedoch dieses Kommando prüft, ob configdb genutzt wird und gibt dann eben eine GROßE und DEUTLICHE Warnung aus, dass man die Daten der SQL Datenbank mit entsprechenden Hilfmitteln (je nach eingesetzter DB) sichern muss.

Und ganz nebenbei fände ich es noch toll, wenn nach dem Backup der FHEM Screen wieder erscheint 

Viele Grüße

Klaus