Rückmeldung zu: update neu geschrieben

[betateilchen]

@betateilchen:
nein, hoechstens dass es nicht funktioniert.

ok. Es funktioniert bei mir nicht mehr.

Besser formuliert?

[rudolfkoenig]

Nicht ausreichend besser, da es bei mir funktioniert.
Also bitte soviel sagen, dass ich es nachstellen, oder wenigstens eingrenzen kann.

[betateilchen]

Ich hatte gestern vor dem Update das globale Attribut gesetzt auf "00_HMLAN.pm,10_CUL_HM.pm,HMConfig.pm" weil ich wusste, dass die Dateiversionen aus dem SVN zu diesem Zeitpunkt schon aktueller und fehlerbereinigt waren, aber die drei Dateien wurden trotzdem (kaputt-)aktualisiert, auch klar erkennbar im Logfile.

Mehr kann ich zum Nachstellen nicht bieten.

[scooty]

Hallo Rudolf,

in der nicht-blockierenden updateInBackground=1 Variante sehe ich nur ein Update bzw. Backup, d.h. diese Version is mAn vom Problem nicht betroffen.

Leider doch, mit updateInBackground=1 wurden sogar drei Backup-Dateien erzeugt, hier das "zusammengedampfte" Log "updateInBackground1.txt" mit den entsprechenden drei Backup-Kommandos:

Code Auswählen Erweitern

.
.
2014.08.27 11:17:56 2: Backup with command: tar -cf - fhem.cfg ./log/fhem.save /opt/fhem/CHANGED /opt/fhem/config /opt/fhem/configDB.pm /opt/fhem/contrib /opt/fhem/credentials.cfg /opt/fhem/demolog /opt/fhem/docs /opt/fhem/FHEM /opt/fhem/fhem.cfg /opt/fhem/fhem.cfg.demo /opt/fhem/fhem.pl /opt/fhem/log /opt/fhem/README_DEMO.txt /opt/fhem/restoreDir /opt/fhem/unused /opt/fhem/www |gzip > /opt/fhem/backup/FHEM-20140827_111753.tar.gz
.
.
2014.08.27 11:19:01 2: Backup with command: tar -cf - fhem.cfg ./log/fhem.save /opt/fhem/CHANGED /opt/fhem/config /opt/fhem/configDB.pm /opt/fhem/contrib /opt/fhem/credentials.cfg /opt/fhem/demolog /opt/fhem/docs /opt/fhem/FHEM /opt/fhem/fhem.cfg /opt/fhem/fhem.cfg.demo /opt/fhem/fhem.pl /opt/fhem/log /opt/fhem/README_DEMO.txt /opt/fhem/restoreDir /opt/fhem/unused /opt/fhem/www |gzip > /opt/fhem/backup/FHEM-20140827_111901.tar.gz
.
.

2014.08.27 11:20:11 2: Backup with command: tar -cf - fhem.cfg ./log/fhem.save /opt/fhem/CHANGED /opt/fhem/config /opt/fhem/configDB.pm /opt/fhem/contrib /opt/fhem/credentials.cfg /opt/fhem/demolog /opt/fhem/docs /opt/fhem/FHEM /opt/fhem/fhem.cfg /opt/fhem/fhem.cfg.demo /opt/fhem/fhem.pl /opt/fhem/log /opt/fhem/README_DEMO.txt /opt/fhem/restoreDir /opt/fhem/unused /opt/fhem/www |gzip > /opt/fhem/backup/FHEM-20140827_112011.tar.gz
.
.

In der blockierenden Version sind es zwei updates, nach Abschluss des ersten updates+backup, was leider genau eine Minute dauert, schickt der Browser eine zweite Aufforderung, ich gehe davon aus, dass dies nicht manuell ausgeloest wurde, um mich zu aergern

Und so etwas traust Du mir zu?   
Nein, manuell wurde von mir nichts ausgelöst.

Neue Fragen:
- welchen Browser verwendest du bzw. tritt das Problem auch mit einem anderen auf

Chrome und Firefox zeigen das gleiche Verhalten.

- ist das FHEMWEB Attribut redirectCmds gesetzt?

Nicht explizit, daher gehe ich davon aus, dass der Defaultwert 1 benutzt wird.

- tritt das Problem auch in der leeren "Home-Ansicht" auf? Mit "Home Ansicht" meine ich die Seite ohne Geraete, die man nach dem Klick auf das FHEM-Icon bekommt.

Ja, die heutigen update-Testläufe (mit Chrome und Firefox) habe ich explizit aus der "Home-Ansicht" gestartet.

Vielen Dank fürs Kümmern,
Andreas

[betateilchen]

In der blockierenden Version sind es zwei updates, nach Abschluss des ersten updates+backup, was leider genau eine Minute dauert, schickt der Browser eine zweite Aufforderung

Meine Rede, seit mehreren Wochen, zu diesem Thema, zuletzt hier im Thread:

Das Problem mit der doppelten Ausführung von im Frontend eingegebenen Befehlen tritt fhem-weit (!) immer dann auf, wenn eine Aktion länger als (circa) 60 Sekunden dauert. Warum auch immer. (Browser Problem? Javascript Problem? FHEMWEB Problem?)

Per Telnet tritt das Phänomen nie auf.

Das Fehlverhalten ist nicht browserspezifisch - zumindest konnte ich bisher keinen (gängigen) Browser finden, in dem das Problem nicht auftritt.

[rudolfkoenig]

@betateilchen:
laut (alten) Doku war exclude_from_update auch frueher schon space getrennt (und jetzt auch), aber frueher wurde die Dateiname als Regexp gegen dem ganzen Attribut geprueft ($exclude =~ m/$fname/, mAn etwas verrueckt), deswegen klappt es aber auch mit Komma. Jetzt wird das Attribut an Space aufgeteilt, und jeder der Teile wird geprueft ($fname =~ m/$excl[$i]/).
Ich wuerde gerne bei meiner Loesung bleiben, falls nix Wesentliches dagegen spricht.
@ scooty: ich schau das heute Abend mal an.

[betateilchen]

Ich habe kein Problem damit, von Komma auf Leerzeichen umzustellen, wenn es anders nicht (mehr) funktioniert.

Was ich aber völlig schräg finde, ist die Tatsache, dass solche Listenangaben in Attributen fhemweit völlig willkürlich definiert sind. Mal mit Komma, mal mit Leerzeichen und was weiß ich noch alles. Man muss eigentlich für jedes Modul erstmal ergründen, was nun die korrekte Syntax ist. Könnte man nicht Bestrebungen einleiten, das generell zu vereinheitlichen? In diesem Fall wäre ich dann doch wieder für eine kommagetrennte Liste, da Attributwerte in Listen ja durchaus auch Leerzeichen enthalten können wie bei room(s) und group(s)

[betateilchen]

Neue Erkenntnisse zum Thema:

Mit Leerzeichen zur Trennung funktioniert es grundsätzliche.

Aber... zwei Probleme gibt es trotzdem:

• die ausgelassenen Dateien sollten mit einem entsprechenden Vermerk ebenso geloggt werden wie die tatsächlich aktualisierten, sonst kommt man nie drauf, dass da Dateien ausgelassen wurden.
• löscht man nach dem update das attribute exclude_from_update und führt dann nochmal ein Update aus, werden die fehlenden Dateien nicht aktualisiert. Vermutlich weil das lokale Kontrollfile vom Auslassen nix mitbekommen hat.

[Bennemannc]

Hallo,

bei mir wird immer mich bei einem Update Check ein altes Restoreverzeichnis gelöscht und ein neues leeres angelegt. Wenn ich das drei Tage hintereinander mache, habe ich keine Dateien mehr, die ich zurückspielen könnte.
Könnte jemand das mal prüfen, oder bin ich der einzigste bei dem das so passiert. Das löschen wird übrigens im WebIf angezeigt, das Neuanlegen nicht.

Gruß Christoph

PS. Update Check sagte Nothing to do - ein anschließendes Update hat zwei Dateien upgedatet.

[ph1959de]

Parameter restoreDirs in der commandref "ist Dein Freund"...

[krikan]

"Wiki-Promotion" oder: http://www.fhemwiki.de/wiki/FHEM_Command_Beispiele#update_... und den dort verlinkten Ankündigungs-Beitrag von Rudi

PS: Wiki-Verbesserungen erwünscht...

[Bennemannc]

Hallo,

damit komme ich nicht weiter. Ich habe "update check" gemacht. Dort soll eigentlich nur geprüft werden ob es neue Versionen gibt.
Das Ergebnis war, ein altes RestoreDir wurde gelöscht, ein neues leeres mit heutigem Datum angelegt und angezeigt "Nothing to do ...".
Wenn nur gecheckt wird, warum werden dabei schon Verzeichnisse gelöscht und erstellt ?
Anschließend habe ich ein "update" eingegeben und es wurden zwei Dateien erneuert. Wieso wurden diese bei Check nicht angezeigt ?
Das mit den 3 RestoreDirs finde ich vollkommen ok. Wenn aber jetzt der Check schon eines löscht und ein neues anlegt, habe ich nach drei Checks ohne zwischenzeitliches Update drei leere Verzeichnisse.

Gruß Christoph

[betateilchen]

Stimmt. Das Löschen und Anlegen der Verzeichnisse sollte noch verbessert werden. Ich denke, da muss Rudi nochmal ran

Anlegen eines Verzeichnisses nur, wenn es auch wirklich benutzt wird.

[rudolfkoenig]

@Bennemannc: kann ich nicht nachvollziehen, anlegen und loeschen der restoreDirs werden bei check nicht durchgefuehrt (war auch so Absicht, sicherheitshalber gerade getestet). Allerdings war die Pruefung auch check/all/force nicht case insensitive, das habe ich jetzt geaendert.

@betateilchen: ich habe jetzt eine zusaetzliche Ausgabe beim Anlegen der restoreDir/YYYY-MM-DD Verzeichnis, sowie beim skippen einer Datei in der Exclude-Liste (letzteres allerdings nur loglevel 4) hinzugefuegt.
Und man kann jederzeit einzelne Dateien mit Angabe der Dateiname herunterladen, unabhaengig vom controlfile, da wird die lokale control-Datei auch nicht erneuert.

[Bennemannc]

Hallo Rudolf,

dann werde ich morgen mal mit verbose 5 loggen, mal sehen was da abgeht. Bei mir ist dieses Verhalten reproduzierbar (FB 7362 SL).
Ich habe aber auch noch folgende Meldung im Log stehen, mit der ich nichts anfangen kann.

Code Auswählen Erweitern

/etc/version: /etc/init.d/rc.conf: line 4: can't create /var/env: Permission denied
rm: can't remove '/var/htmltext.db': Permission denied
ln: /var/htmltext.db: File exists
rm: can't remove '/var/TZ': Permission denied
ln: /var/TZ: File exists
Bei der Fritte kann man doch nichts nach /etc/init.d/ schreiben - das ist doch readonly. /var/env ist -rw-r--r-- root root, das könnte man mit chown oder chmod ändern, aber da stehen Daten von AVM drin. /var/htmltext.db ist ein Link auf /etc/htmltext.db - also ro Dateisystem, /var/TZ geht ebenfalls nach /etc/...
Das Ganze kommt seit kurzem nach jedem shutdown restart.

Gruß Christoph