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?
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.
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.
Zitat von: betateilchen am 18 April 2014, 11:21:14
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?
Zitat von: maxritti am 18 April 2014, 12:12:52
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.
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
Zitat- 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.
ZitatWenn "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
Das update hat das protokolliert:
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:
Zitat von: betateilchen am 18 April 2014, 12:18:51
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.
Zitat2014.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.
Zitat von: betateilchen am 18 April 2014, 12:31:24
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. :o
Wenn dem nicht so ist, dann sollte man den Hinweise "shutdown restart" eventuell ganz löschen und jedesmal einen Neustart machen.
Zitat von: Joachim am 18 April 2014, 12:22:20
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.
Zitat von: maxritti am 18 April 2014, 12:40:25
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.
@ betateilchen,
ZitatDie 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
Zitat von: betateilchen am 18 April 2014, 12:46:01
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 ;)
Zitat von: Joachim am 18 April 2014, 13:00:54
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 :)
Zitat von: maxritti am 18 April 2014, 13:03:15Ist 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 8)
Scheint ja jetzt alles geklärt zu sein. Ich hoffe mal, dass rudi hier mitliest.
Das Posting hier ist wieder offen für Antworten.
Danke dafür.
@betateilchen:
Waiting for your comments.. :)
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.
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.
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"
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
Seit Version 5.5 exisitert in den fhem Verzeichnis ein kleines backup-skript, das perl nicht sichert:
#!/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
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
@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.
Danke Rudi
Gruß Joachim
das klingt irgendwie so, als könnten morgen nach dem Update meine Kalender wieder in den Streik treten *lach*
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?
Calendar bestellt explizit ein shutdown (noshutdown==0), auch beim https.
Dieser Parameter wird ab jetzt (wie vorher) bei https ignoriert.
Danke, funktioniert.
(http://up.picr.de/18021176gd.jpg)