Bug in 98_update.pm ?

[maxritti]

Hallo zusammen,

ich habe jetzt mal in die Maintainer.txt geschaut um die richtige Gruppe zu finden, wo ich denke dass meine Frage bzw das Problem hingehört.

Bedingt durch folgende beiden Postings, wo ein update nicht zu dem gewünschten Ergebnis führt, gehe ich mal von einem Bug im Update Modul aus.

http://forum.fhem.de/index.php/topic,16503.msg160115.html#msg160115

http://forum.fhem.de/index.php/topic,20184.msg137359.html#msg137359

Erst wenn ich ein "update force" mache, werden die neuen Änderungen an Modulen wirksam.

In der Commandref steht, dass ein "update force" alle Dateien aktualisiert.
Dahingegen wird dann ein "update" wohl nur wirklich neuere Dateien aktualisieren.
So recht will es mir aber nicht klar werden, warum ein "update" nichts mehr zu tun hat, dann ein "update force" aber augenscheinlich Änderungen an Modulen wirksam werden lässt.

Hat dazu jemand eine Idee, wie ich hier den Fehler eingrenzen könnte?

[betateilchen]

Beschreibe bitte mal genau, was Dein angebliches Problem ist - weder aus Deinem Beitrag hier noch aus den beiden verlinkten Beiträgen erschließt sich mir das wirklich.

Ein "update force" funktioniert immer und lädt sämtliche fhem-Dateien, unabhängig von ihrem Versionsstand vor dem Update.

Ein "update" aktualisiert nur die Dateien, die sich seit ihrer letzten Aktualisierung Deines Systemes verändert haben. Die Notwendigkeit des Updates einer Datei wird dabei aus einem Vergleich der Versionsnummern dieser Datei erkannt. Dazu gibt es auf Deinem System eine Steuerdatei, die mit der aktuellen Steuerdatei auf dem fhem-Server verglichen wird. Gibt es Unterschiede, werden genau die Unterschiede aktualisiert.

Wenn ein Update scheinbar nicht funktioniert, kann das mehrere Ursachen haben.

Die einfachste: es gibt nichts zu aktualisieren.

Das ist zum Beispiel der Fall, wenn Du morgens um 09:00 Uhr ein Update durchführst und dann abends um 20:00 Uhr nochmal probierst, ein Update zu machen. fhem stellt Updates nur einmal pro Tag zusammen und baut die genannte Steuerdatei. Das passiert morgens irgendwann zwischen 0700 und 0800 Uhr. Die nächste Generierung der Steuerdatei erfolgt dann erst am nächsten Morgen wieder. Bis zum nächsten Morgen wird also immer gegen die bestehende Steuerdatei verglichen. Selbst wenn ein Entwickler im Laufe des Tages drei neue Modulversionen bereitstellt, sind die per Update erst am nächsten Morgen, nach Neugenerierung der Steuerdatei verfügbar. (Per SVN stehen sie sofort bereit).

Weitere Möglichkeiten:

- Du hast eine Datei per "exclude_from_update" ausgeschlossen. Dann bekommst Du aber immer noch eine Meldung vom Updateprozess
- zerschossene Steuerdatei auf Deinem System (das habe ich selbst noch nie erlebt, da diese Datei eigentlich vom Anwender nie angefasst wird) Auch dann wird eine entsprechende Meldung ausgegeben.
- Ein Update wurde abgebrochen. Die aktuelle Steuerdatei wurde bereits während des updates geladen (das passiert immer als allererstes) und der nachfolgend noch einmal gestartete update-Prozess findet deshalb logischerweise keine Änderungen mehr zwischen der Steuerdatei auf Deinem fhem und der Steuerdatei auf dem fhem-Webserver. Das ist dann der Punkt, an dem das "update force" funktioniert, denn diese Variante kümmert sich nicht um die Steuerdatei und lädt alles, was auf dem fhem-Webserver bereitsteht.

Wenn "Nothing to do" angezeigt wird, kannst Du dieser Meldung in 99,99% aller Fälle vertrauen.

[maxritti]

Also der Fall war so wie in dem Dashboard-Post erläutert.

Heute morgen habe ich (wie fast jeden Tag) ein Update gemacht.
Somit sollte mein fhem aktuell sein.

Dann habe ich im Dashboard festgestellt,. dass der "Lock" Button nicht funktioniert.

Daraufhin meinte svenson08, dass mein Update nicht geklappt hat.

Also mal ein "update check" gemacht, was "nothing to do" als Ergebnis hatte.
Heisst für mich: "Alles aktuell".

Aber das Dashboard war nicht korrekt.

Dann ein "update force"

Und siehe da: Danach war der Button "Lock" im Dashboard nicht mehr da.
Heisst für mich, dass das "update force" etwas aktualisiert hat, was das "update" nicht gemacht hat.

Ich hoffe jetzt ist das Problem klar.

[maxritti]

Weitere Möglichkeiten:

- Du hast eine Datei per "exclude_from_update" ausgeschlossen. Dann bekommst Du aber immer noch eine Meldung vom Updateprozess
- zerschossene Steuerdatei auf Deinem System (das habe ich selbst noch nie erlebt, da diese Datei eigentlich vom Anwender nie angefasst wird) Auch dann wird eine entsprechende Meldung ausgegeben.
- Ein Update wurde abgebrochen. Die aktuelle Steuerdatei wurde bereits während des updates geladen (das passiert immer als allererstes) und der nachfolgend noch einmal gestartete update-Prozess findet deshalb logischerweise keine Änderungen mehr zwischen der Steuerdatei auf Deinem fhem und der Steuerdatei auf dem fhem-Webserver. Das ist dann der Punkt, an dem das "update force" funktioniert, denn diese Variante kümmert sich nicht um die Steuerdatei und lädt alles, was auf dem fhem-Webserver bereitsteht.

Wenn "Nothing to do" angezeigt wird, kannst Du dieser Meldung in 99,99% aller Fälle vertrauen.

- exclude_from_update ist nicht gesetzt
- zerschossene Steuerdatei?
Habe ich manuell noch nie angefasst, da ich gar nicht weiss, wo die liegt?
Wie könnte man diese denn erneuern?
Vielleicht liegt da ja der Hase im Pfeffer begraben.

- Update abgebrochen
Wie könnte man das denn prüfen?

[betateilchen]

Heute morgen habe ich (wie fast jeden Tag) ein Update gemacht.

Wann heute morgen? Was steht im Logfile zu diesem ersten Updateversuch?

Lass Dir doch die Würmer nicht all einzeln aus der Nase ziehen.

[Joachim]

Moin maxritti, Moin betateilchen,

Da ich ausführlich im Forum mitlese, bin ich der gleichen Meinung, wie maxritti, und kann mich an gefühlte 100 Treads erinnern, bei denen es Probleme beim update gab (bin zu faul, die jetzt herauszusuchen), in 99% der Fälle war ein update force die Lösung, teilweise musste auch die Steuerdatei gelöscht werden. Irgendetwas ist hier im argen, nur was?
Ich meine mich daran erinnern zu können, dass es relativ häufig in Verbindung mit Neuinstallationen war.
Es macht also durchaus Sinn, den Updateprozess mal abzuklopfen.
Mein Bauchgefühl sagt mir,dass

- Ein Update wurde abgebrochen. Die aktuelle Steuerdatei wurde bereits während des updates geladen (das passiert immer als allererstes)

nicht ungefährlich ist, und zu schwer einzugrenzenden Problemen führt.

Wenn "Nothing to do" angezeigt wird, kannst Du dieser Meldung in 99,99% aller Fälle vertrauen.

genau das ist ein Problem, man kann dieser Meldung leider nicht vertrauen, da sie sich auf die Steuerdatei verlässt.
Eine Lösung wäre, die ID mindestens einer geänderten Datei zu überprüfen.
Wenn ich heute im laufe des Tages die Zeit finde, werde ich mal die gefühlten 100 Treads suchen, vielleicht liefern die ja einen Anhaltspunkt.
Jetzt muss ich allerdings ersteinmal mehrere Computer XP-Frei machen, und dafür Kubuntu aufspielen.

Gruß Joachim

[maxritti]

Das update hat das protokolliert:

Code Auswählen Erweitern

2014.04.18 08:09:01 3: CUL_HM set EG_wz_RO_TerrasseRechts on
2014.04.18 08:14:01 3: update get http://fhem.de/fhemupdate4/svn/controls_fhem.txt
2014.04.18 08:14:11 3: update get http://fhem.de/fhemupdate4/svn/FHEM/FhemUtils/release.pm
2014.04.18 08:14:11 1: update check Releases => local: Fhem 5.5 (DEVELOPMENT) remote: Fhem 5.5 (DEVELOPMENT)
2014.04.18 08:14:11 3: update get http://fhem.de/fhemupdate4/svn/controls_fhem.txt
2014.04.18 08:14:11 1: update saving statefile
2014.04.18 08:14:11 3: update get http://fhem.de/fhemupdate4/svn/./CHANGED
2014.04.18 08:14:11 3: update get http://fhem.de/fhemupdate4/svn/FHEM/00_TCM.pm
2014.04.18 08:14:12 3: update get http://fhem.de/fhemupdate4/svn/FHEM/02_RSS.pm
2014.04.18 08:14:12 3: update get http://fhem.de/fhemupdate4/svn/FHEM/10_CUL_HM.pm
2014.04.18 08:14:12 3: update get http://fhem.de/fhemupdate4/svn/FHEM/10_EnOcean.pm
2014.04.18 08:14:13 3: update get http://fhem.de/fhemupdate4/svn/FHEM/10_FRM.pm
2014.04.18 08:14:13 3: update get http://fhem.de/fhemupdate4/svn/FHEM/13_KS300.pm
2014.04.18 08:14:13 3: update get http://fhem.de/fhemupdate4/svn/FHEM/21_OWLCD.pm
2014.04.18 08:14:13 3: update get http://fhem.de/fhemupdate4/svn/FHEM/70_Pushover.pm
2014.04.18 08:14:13 3: update get http://fhem.de/fhemupdate4/svn/FHEM/95_Dashboard.pm
2014.04.18 08:14:13 3: update get http://fhem.de/fhemupdate4/svn/FHEM/98_HMinfo.pm
2014.04.18 08:14:13 3: update get http://fhem.de/fhemupdate4/svn/FHEM/HMConfig.pm
2014.04.18 08:14:14 3: update get http://fhem.de/fhemupdate4/svn/FHEM/lib/Device/Firmata.pm
2014.04.18 08:14:14 3: update get http://fhem.de/fhemupdate4/svn/FHEM/lib/Device/Firmata/Platform.pm
2014.04.18 08:14:14 3: update get http://fhem.de/fhemupdate4/svn/docs/commandref.html
2014.04.18 08:14:16 3: update get http://fhem.de/fhemupdate4/svn/docs/commandref_DE.html
2014.04.18 08:14:16 3: update get http://fhem.de/fhemupdate4/svn/www/pgm2/dashboard.js
2014.04.18 08:14:17 3: update get http://fhem.de/fhemupdate4/svn/www/pgm2/fhemweb.js
2014.04.18 08:14:17 1: update 18 file(s) have been updated.

Das "update force" habe ich dann etwas später angeschmissen:

Lass Dir doch die Würmer nicht all einzeln aus der Nase ziehen.

Sorry, wenn man immer wüsste wann wo und was zu liefern wäre, wäre das FHEM Leben gewiss einfacher.

[betateilchen]

2014.04.18 08:14:13 3: update get http://fhem.de/fhemupdate4/svn/FHEM/95_Dashboard.pm

Da wurde aber Dein Dashboard aktualisiert.

Doofe Frage: nach dem ersten Update hattest Du Dein fhem aber schon neugestartet, oder? Ansonsten nützt Dir das ganze Update nämlich nichts, denn die neuen Modulversionen werden erst nach einem Neustart benutzt.

[maxritti]

Doofe Frage: nach dem ersten Update hattest Du Dein fhem aber schon neugestartet, oder? Ansonsten nützt Dir das ganze Update nämlich nichts, denn die neuen Modulversionen werden erst nach einem Neustart benutzt.

Natürlich nicht.
Hat fhem mir ja auch nicht gesagt.
Dachte halt, dass das nur notwendig sei, wenn das update das auch erwähnt. War dann wohl ein Irrtum. 

Wenn dem nicht so ist, dann sollte man den Hinweise "shutdown restart" eventuell ganz löschen und jedesmal einen Neustart machen.

[betateilchen]

in 99% der Fälle war ein update force die Lösung, teilweise musste auch die Steuerdatei gelöscht werden. Irgendetwas ist hier im argen, nur was?

Das kann ich Dir für 99% der 99% der Fälle ziemlich klar beschreiben: Die Anwender haben nach der Erstinstallation ihres fhem eine "update" gestartet und es ist SCHEINBAR nichts passiert - es gab keinerlei Rückmeldung im Frontend. Daraufhin haben sie aus Unwissenheit ihr fhem neugestartet, das Update abgebrochen oder irgendwas anderes gemacht, das man zu diesem Zeitpunkt besser hätte seinlassen.

In Wirklichkeit dauert das erste Update nach einer Neuinstallation SEHR SEHR lange und man erkennt im Frontend wirklich nichts.
Erschwerend kommt hinzu, dass standardmäßig das Update im Vordergrund ausgeführt wird und für die gesamte Ausführungszeit des Update fhem blockiert ist - solange, bis die Erfolgsmeldung vom update-Modul ausgegeben wird. Würde man in einem parallelen Browserfenster den Eventmonitor beobachten, könnte man durchaus erkennen, dass sich "etwas tut" - auch wenn man im Frontend selbst erstmal nix sieht.

Die Steuerdatei ist die erste, die geladen wird (geladen werden muss!) deshalb schlägt nach einem solchen Abbruch jeder weitere Updateversuch am gleichen Tag fehl. Und zwar so lange, bis man entweder ein update force durchführt oder die Steuerdatei löscht.

Es handelt sich nicht um einen Fehlverhalten von fhem bzw. dem update-Modul, sondern resultiert aus einem "Fehlverhalten" der Anwender, nämlich aus Ungeduld.

Besonders gravierend trifft das Fritzkotz-Nutzer, weil durch die schwachbrüstige Hardware das Update nochmal viel länger dauert als auf einer ordentlichen Hardware.

[betateilchen]

Natürlich nicht.
Hat fhem mir ja auch nicht gesagt.

fhem wird Dich nach dem Update nur dann explizit zum "shutdown restart" auffordern, wenn die Datei "fhem.pl" per update aktualisiert wurde.
Bei JEDER Aktualisierung irgendeines verwendeten Moduls muss fhem neugestartet werden, damit das Update wirksam wird.

Ich habe mir angewöhnt, nach einem Update grundsätzlich ein "shutdown restart" durchzuführen, egal was aktualisiert wurde.

[Joachim]

@ betateilchen,

Die Steuerdatei ist die erste, die geladen wird (geladen werden muss!) deshalb schlägt nach einem solchen Abbruch jeder weitere Updateversuch am gleichen Tag fehl. Und zwar so lange, bis man entweder ein update force durchführt oder die Steuerdatei löscht.

Es handelt sich nicht um einen Fehlverhalten von fhem bzw. dem update-Modul, sondern resultiert aus einem "Fehlverhalten" der Anwender, nämlich aus Ungeduld.

Mir ist bekannt, dass das erste Update lange dauert, gerade auf einer Fritzbox. Aber nach meiner Meinung ist es ein Programmfehler, wenn nach einem nicht zuende durchgeführtem Update so getan wird, als hätte es geklappt.
Dem Anwender wird damit signalisiert, dass das Update funktioniert hat, das ist ein "noGo".
Wenn der Ablauf wirklich so ist, dann ist der Bug lokalisiert, und die Lösung wäre:
Steuerdatei in temporäres Verzeichnis, oder das RAM laden, Anweisungen ausführen, als letzten Schritt Steuerdatei an die richtige Stelle verschieben.
Sollte dann bei dem Updateprozess irgendetwas schieflaufen (Systemabsturz, Anwendereingriff, fehlende Schreibberechtigung, etc.) würde weiterhin ein update angeboten werden.

Gruß Joachim

[maxritti]

fhem wird Dich nach dem Update nur dann explizit zum "shutdown restart" auffordern, wenn die Datei "fhem.pl" per update aktualisiert wurde.
Bei JEDER Aktualisierung irgendeines verwendeten Moduls muss fhem neugestartet werden, damit das Update wirksam wird.

Ich habe mir angewöhnt, nach einem Update grundsätzlich ein "shutdown restart" durchzuführen, egal was aktualisiert wurde.

Na wenn Du das schon so machst, dann sollte man bzw das update das doch allgemein so machen, bevor andere darüber stolpern.
Oder aber immer einen Hinweis, dass ein Neustart notwendig ist. Ist zwar Windows like, aber wenn es denn hilft 

[betateilchen]

Wenn der Ablauf wirklich so ist, dann ist der Bug lokalisiert, und die Lösung wäre:
Steuerdatei in temporäres Verzeichnis, oder das RAM laden, Anweisungen ausführen, als letzten Schritt Steuerdatei an die richtige Stelle verschieben.
Sollte dann bei dem Updateprozess irgendetwas schieflaufen (Systemabsturz, Anwendereingriff, fehlende Schreibberechtigung, etc.) würde weiterhin ein update angeboten werden.

Ja, darüber kann Rudi ja mal nachdenken

[betateilchen]

Ist zwar Windows like, aber wenn es denn hilft

Nun, Windows User sollten das ja durch ihr jahrelanges "Training" auch ohne Hinweis kennen und Linux-User sollten genug Verstand besitzen, um da selbst drauf zu kommen