Bug in 98_update.pm ?

[maxritti]

Scheint ja jetzt alles geklärt zu sein. Ich hoffe mal, dass rudi hier mitliest.

[maxritti]

Das Posting hier ist wieder offen für Antworten.
Danke dafür.

@betateilchen:

Waiting for your comments.. 

[betateilchen]

nunja, ich wollte einfach noch anmerken, dass eine frühere Version von 98_update.pm durchaus die Möglichkeit bot, dem Anwender nach einem Update die Meldung "shutdown restart required" nicht nur nach Aktualisierung der fhem.pl sondern auch nach der Aktualisierung eines oder mehrerer verwendeter (!) Module zu präsentieren.

Ich weiss nicht warum (und nicht genau wann) diese Meldung ausgebaut wurde - aber vielleicht könnte eine Reaktivierung dieses Hinweises schon eine spürbare Verbesserung bringen.

[rudolfkoenig]

Vorneweg: update.pm ist eigentlich von Martin, und ich betreue es z.Zt komissarisch.

Neustart ist seit laengerem immer notwendig. Frueher hat update die geaenderten Module per reload reingeladen (sehr elegant), das ist aber gefaehrlich (d.h. FHEM kann dabei abstuerzen, wenn das Modul neue Variablen im define definiert). Da wir die Probleme nicht einfach ausschliessen koennen, wird z.Zt. kein reload gemacht.

Seit FHEM 5.5. enthaelt fhem.cfg das Attribut "attr global updateInBackground", das wird aber nicht nachtraeglich aktualisiert. Mit dem Attribut werden alle Meldungen an das Frontend (FHEMWEB oder telnet) direkt weitergeschickt, d.h. der Benutzer sieht "live" den update, ohne das Attribut kommt alles zum Schluss.

Update Fehler: ich vermute auch, dass das Problem in "zuerst control-file update und dann update abgebrochen" besteht, ohne den Code wirklich zu kennen.

[betateilchen]

fhem sollte sich irgendwo "merken" ob das letzte Update korrekt durchgelaufen ist. Falls nicht, sollte beim nächsten update entsprechend reagiert werden und nicht mit  "Nothing to do"

[Ich79]

Hi!
Ich bin auch einer der Fritzbox Benutzer. Allerdings aus "Stromspargründen". Da die Box eh läuft...
Wohl wahr. Das Update braucht wirklich recht lange auf der 7490 (ca 3 Minuten). Der überwiegende Teil der Zeit geht aber nur für das Backup drauf. Wenn ich mir das genauer ansehe, ist ein großer Teil das Backup von Perl.
Wäre es vielleicht eine Option beim Backup modul ein "excludeFromBackup" Attribut einzuführen, in dem man Pfade hinterlegen kann, die NICHT mit ins Backup kommen? Dann könnte ich Perl endlich ausschliessen. Ich denke für manche wird auch das Sichern der grlösseren Log Sammlung interessant sein. Bei mir habe ich die Log Archive schon extra woanders hin verschoben, damit die nicht immer mitgesichert werden.

Wäre für mich eine lange gewünschte Neuerung. Allerdings bin ich kein Perl Entwickler. Die Schleife, die durch die Verzeichnisse geht habe ich zwar gefunden, dann ist bei mir aber Ende mit Verständnis...

Viele Grüße
Boris

[rudolfkoenig]

Seit Version 5.5 exisitert in den fhem Verzeichnis ein kleines backup-skript, das perl nicht sichert:

Code Auswählen Erweitern

#!/bin/sh

# optional backup command to speed up backup on th FB by omitting the backup of
# the perl directory. To use it set attr global backupcmd backup.sh

tar cf - FHEM fhem.cfg fhem.pl log startfhem* www |
gzip -3 > backup/backup-`date -I`.tar.gz
echo backup done
exit 0


[Joachim]

Moin Rudi,

habe mir das ganze heute nacht nocheinmal durch den Kopf gehen lassen, und dabei ist mir aufgefallen, das der jetzige Weg einen riesen Bug darstellt.
Und zwar aus folgendem Grund:
Update wird durchgeführt, und läuft nicht durch, das bedeutet es gibt eine neue Steuerdatei, obwohl nicht aktualisiert worden ist. Anwender glaubt, es ist alles in ordnung.
Tage später wird wieder ein Update gemacht. Dabei wird die Steuerdatei des abgebrochenen Updates genommen.
Katastrophe perfekt, da die geänderten Dateien vom vorherigen Update fehlen.

Dass muß geändert werden, da die Seiteneffekte nicht zu beherrschen sind, und jetzt ggf. Inkonsistenzen entstehen.

Gruß Joachim

[rudolfkoenig]

@Joachim: die Konsequenzen waren mir schon bewusst, wie ich vorhin meine Vermutung geschrieben habe. Ich habe mich bisher von Aenderungen in update.pm gescheut, weil es so gar nicht in meinem Stil geschrieben ist. Hatte gehofft, dass hier einer sich stuermisch meldet, Patches schreibt, und ich update dann weitergeben kann

Ich habe jetzt aber Zeit investiert, herumexperimentiert, und was geaendert: die Kontrolldatei wird jetzt nicht mehr geschrieben, falls einer der Dateien nicht korrekt von fhem.de geholt wurde, oder die Outputdatei nicht geoeffnet werden konnte (war vorher der Fall). Es wird aber immer noch geschrieben, falls einer der Dateien nicht komplett gespeichert werden konnte (Festplatte voll).

Da ich im Moment hinter einem Proxy (squid) sitze, hat das update auch erstmal nicht funktioniert, bis ich den beruehmt beruechtigten shutdown in HttpUtils.pm auskommentiert habe. Das hat dazu gefuehrt, dass shutdown per default jetzt aus ist, wer es haben will, muss es ab sofort per noshutdown=0 aktivieren. HttpUtils_NonblockingGet Benutzer koennen auch den optionalen shutdown=1 verwenden. Ich vermute diese Aenderung wird nicht ohne Konsequenzen sein, bitte fuer Fehlermeldungen eine neue Diskussion oeffnen.

[Joachim]

Danke Rudi

Gruß Joachim

[betateilchen]

das klingt irgendwie so, als könnten morgen nach dem Update meine Kalender wieder in den Streik treten *lach*

[betateilchen]

Es war ja zu befürchten...

(http://up.picr.de/18020108pr.png)

• um 09:02 war das letzte korrekte Update der Kalenderdaten.
• um 09:10 kam das fhem Update der HttpUtils
• um 09:12 konnten beim Restart nach dem Update keine Kalenderdaten mehr gelesen werden

(http://up.picr.de/18020041sl.png)

Wo soll ich nun welches Attribut auf welchen Wert setzen, damit meine Kalender wieder funktionieren?

[rudolfkoenig]

Calendar bestellt explizit ein shutdown (noshutdown==0), auch beim https.
Dieser Parameter wird ab jetzt (wie vorher) bei https ignoriert.

[betateilchen]

Danke, funktioniert.

(http://up.picr.de/18021176gd.jpg)