Hallo,
seit ein paar Wochen meldet das Update von fhem immer "nothing to do" obwohl im logfile ersichtlich ist, dass Updates geladen wurden.
Dieses Verhalten ist unter Windows-Firefox und Android bei mir das Selbe.
Gruss
Joe
update force mal getestet?
@chris1284: "update force" bitte nicht als Loesung empfehlen, oder wenn, dann erst nachdem man das Problem verstanden hat. Es verursacht unnoetig Netzverkehr, wenn es funktioniert, dann kehrt Bugs unterm Teppich und traegt zum VooDoo-Verhalten bei. Wahrscheinlich loest das Problem aber nicht.
@cotecmania: bitte angewoehnen, nachvollziehbare Fehlermeldungen zu posten:
- mit welchen Argumenten wurde update aufgerufen
- welche globalen Parameter sind gesetzt, insb. updateInBackground, restoreDirs, exclude_from_update, backup_before_update
- wann wurde laut FHEM-log das letzte udate gezogen
- welchen Zeitstempel/Groesse hat .../FHEM/controls_fhem.txt, ist sie schreibbar von FHEM?
- von welchem Frontend wurde update gestartet (telnet/FHEMWEB/etc).
- was genau steht im log, und was genu auf dem Bildschirm.
moin rudi,
hatte selbes problem auch schon. einmal über update force alles neu geladen und danach war das problem weg. daher auch der "tip"
Mag sein, aendert aber nichts an meiner Bemerkung: Problem unterm Teppich, andere haben es auch, jeder ruft sicherheitshalber nur noch "update force" auf, keiner weiss wieso. VooDoo halt. Ich habe keine Chance es zu fixen.
habe seit kurzem den selben Fehler.
Hier mein Log:
2015.03.12 08:29:47 2: Backup with command: tar -cf - fhem.cfg ./log/fhem.save /opt/fhem/CHANGED /opt/fhem/configDB.pm /opt/fhem/contrib /opt/fhem/demolog /opt/fhem/docs /opt/fhem/FHEM /opt/fhem/fhem.cfg /opt/fhem/fhem.cfg.demo /opt/fhem/fhem.pl /opt/fhem/fronthem /opt/fhem/fronthem.err /opt/fhem/log /opt/fhem/README_DEMO.txt /opt/fhem/restoreDir /opt/fhem/unused /opt/fhem/www |gzip > /opt/fhem/backup/FHEM-20150312_082947.tar.gz
2015.03.12 08:30:29 1: backup tar: Removing leading `/' from member names
2015.03.12 08:30:29 1: backup done: FHEM-20150312_082947.tar.gz (26002767 Bytes)
2015.03.12 08:30:29 1: RMDIR: /opt/fhem/restoreDir/2015-03-08
2015.03.12 08:30:30 1: UPD ./CHANGED
2015.03.12 08:30:30 1: UPD ./fhem.pl
2015.03.12 08:30:30 1: UPD FHEM/10_RESIDENTS.pm
2015.03.12 08:30:30 1: UPD FHEM/20_GUEST.pm
2015.03.12 08:30:30 1: UPD FHEM/20_ROOMMATE.pm
2015.03.12 08:30:31 1: UPD FHEM/31_LightScene.pm
2015.03.12 08:30:31 1: UPD FHEM/37_SHC.pm
2015.03.12 08:30:31 1: UPD FHEM/37_SHCdev.pm
2015.03.12 08:30:31 1: UPD FHEM/73_PRESENCE.pm
2015.03.12 08:30:31 1: UPD FHEM/90_at.pm
2015.03.12 08:30:31 1: UPD FHEM/98_update.pm
2015.03.12 08:30:31 1: UPD FHEM/RESIDENTStk.pm
2015.03.12 08:30:31 1: UPD FHEM/SHC_parser.pm
2015.03.12 08:30:32 1:
2015.03.12 08:30:32 1: New entries in the CHANGED file:
2015.03.12 08:30:32 1: - feature: GUEST: added support for RESIDENTS toolkit
2015.03.12 08:30:32 1: - feature: ROOMMATE: added support for RESIDENTS toolkit
2015.03.12 08:30:32 1: - feature: RESIDENTS: added support for RESIDENTS toolkit
2015.03.12 08:30:32 1: - added: RESIDENTStk: new RESIDENTS toolkit and first function wakeuptimer
2015.03.12 08:30:32 1: - bugfix: 37_SHC: go back to last release version v0.9.0 (rr2000)
2015.03.12 08:30:32 1: Calling /usr/bin/perl /opt/fhem/contrib/commandref_join.pl, this may take a while
2015.03.12 08:31:07 1: *** EN FHEM/95_WebViewControl.pm: No document text found
EN WifiLight: nonempty line after =begin html ignored
EN FHEM/32_WifiLight.pm: No <a name="WifiLight"> link
*** EN FHEM/01_fronthem.pm: No document text found
*** EN FHEM/31_fronthemDevice.pm: No document text found
*** EN FHEM/99_myUtils.pm: No document text found
DE WifiLight: nonempty line after =begin html ignored
2015.03.12 08:31:07 1:
2015.03.12 08:31:07 1: update finished, "shutdown restart" is needed to activate the changes.
2015.03.12 08:31:07 2: Backup with command: tar -cf - fhem.cfg ./log/fhem.save /opt/fhem/CHANGED /opt/fhem/configDB.pm /opt/fhem/contrib /opt/fhem/demolog /opt/fhem/docs /opt/fhem/FHEM /opt/fhem/fhem.cfg /opt/fhem/fhem.cfg.demo /opt/fhem/fhem.pl /opt/fhem/fronthem /opt/fhem/fronthem.err /opt/fhem/log /opt/fhem/README_DEMO.txt /opt/fhem/restoreDir /opt/fhem/unused /opt/fhem/www |gzip > /opt/fhem/backup/FHEM-20150312_083107.tar.gz
2015.03.12 08:31:45 1: backup tar: Removing leading `/' from member names
2015.03.12 08:31:45 1: backup done: FHEM-20150312_083107.tar.gz (25726548 Bytes)
2015.03.12 08:31:46 1: nothing to do...
Zu deinen Fragen:
-mit welchen Argumenten wurde update aufgerufen
-> update
- welche globalen Parameter sind gesetzt, insb. updateInBackground, restoreDirs, exclude_from_update, backup_before_update
-> nur backup_before_update
- wann wurde laut FHEM-log das letzte update gezogen
-> heute
- welchen Zeitstempel/Groesse hat .../FHEM/controls_fhem.txt, ist sie schreibbar von FHEM?
-> -rw-r--r-- 1 fhem dialout 97274 Mär 12 08:30 controls_fhem.txt
- von welchem Frontend wurde update gestartet (telnet/FHEMWEB/etc).
-> direkt über FHEMWEB
- was genau steht im log, und was genu auf dem Bildschirm.
-> siehe oben
Gruß
Oli
Kannst du bitte den Vorgang mit einem "attr WEB verbose 4" wiederholen?
Ich vermute das Problem liegt daran, dass dein ungeduldiger Browser die Anfrage wiederholt, und ich habe im Moment keine gute Idee, wie man das Problem direkt loest. Falls die Theorie stimmt, dann muesste updateInBackground das Problem indirekt beheben.
Aber gerne.
Update erfolgt aber nun nicht mehr:
2015.03.12 10:11:31 4: HTTP FHEMWEB:192.168.100.80:56815 GET /fhem&cmd=update
2015.03.12 10:11:31 2: Backup with command: tar -cf - fhem.cfg ./log/fhem.save /opt/fhem/CHANGED /opt/fhem/configDB.pm /opt/fhem/contrib /opt/fhem/demolog /opt/fhem/docs /opt/fhem/FHEM /opt/fhem/fhem.cfg /opt/fhem/fhem.cfg.demo /opt/fhem/fhem.pl /opt/fhem/fronthem /opt/fhem/fronthem.err /opt/fhem/log /opt/fhem/README_DEMO.txt /opt/fhem/restoreDir /opt/fhem/unused /opt/fhem/www |gzip > /opt/fhem/backup/FHEM-20150312_101131.tar.gz
2015.03.12 10:12:12 1: backup tar: Removing leading `/' from member names
2015.03.12 10:12:12 1: backup done: FHEM-20150312_101131.tar.gz (25725733 Bytes)
2015.03.12 10:12:12 1: nothing to do...
2015.03.12 10:12:12 4: 4117:FHEMWEB:192.168.100.80:56815: /fhem&cmd=update / RL:1277 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
Zitat von: rudolfkoenig am 12 März 2015, 09:47:22
Ich vermute das Problem liegt daran, dass dein ungeduldiger Browser die Anfrage wiederholt, und ich habe im Moment keine gute Idee, wie man das Problem direkt loest. Falls die Theorie stimmt, dann muesste updateInBackground das Problem indirekt beheben.
Deine Vermutung ist so falsch nicht. Wenn das update länger als eine Minute dauert, wird es nochmal gestartet. Die Erfolgsmeldung erscheint im Frontend aber erst nach dem zweiten Durchlauf, und dann war logischerweise nichts mehr zu tun.
DIe Minutenfrist wird durch die lokale Generierung der commandref nun noch schneller erreicht als vorher.
Die Vermutung, dass updateInBackground das Problem behebt, wage ich zu bezweifeln. Wobei ich durch ein Update im Background vor einiger Zeit noch ganz andere Probleme hatte, weswegen ich bei mir das wieder komplett abgeschaltet habe. Ich ignoriere die Melung "nothing to do" inzwischen einfach, da ich ja weiß, dass das Update trotzdem ausgeführt wurde.
Zitat von: betateilchen am 12 März 2015, 10:54:10
... Ich ignoriere die Melung "nothing to do" inzwischen einfach, da ich ja weiß, dass das Update trotzdem ausgeführt wurde.
Bin also nicht alleine damit ...
- mit welchen Argumenten wurde update aufgerufen
>update
- welche globalen Parameter sind gesetzt, insb. updateInBackground, restoreDirs, exclude_from_update, backup_before_update
>keine, ich sichere wöchentlich mit extra Job
- wann wurde laut FHEM-log das letzte udate gezogen
>Vor 3 Tagen
- welchen Zeitstempel/Groesse hat .../FHEM/controls_fhem.txt, ist sie schreibbar von FHEM?
>95KB vom 13.03.2013
- von welchem Frontend wurde update gestartet (telnet/FHEMWEB/etc).
>FHEMWEB
- was genau steht im log, und was genu auf dem Bildschirm.
>Bildschirm nur "nothing to do"
>LOG heute :
2015.03.13 08:14:47 1: RMDIR: ./restoreDir/2015-03-09
2015.03.13 08:14:48 1: UPD ./CHANGED
2015.03.13 08:14:48 1: UPD FHEM/10_RESIDENTS.pm
2015.03.13 08:14:49 1: UPD FHEM/20_GUEST.pm
2015.03.13 08:14:49 1: UPD FHEM/20_ROOMMATE.pm
2015.03.13 08:14:49 1: UPD FHEM/31_LightScene.pm
2015.03.13 08:14:49 1: UPD FHEM/57_CALVIEW.pm
2015.03.13 08:14:50 1: UPD FHEM/RESIDENTStk.pm
2015.03.13 08:14:50 1: UPD www/pgm2/darksvg_style.css
2015.03.13 08:14:50 1: UPD www/pgm2/svg_style.css
2015.03.13 08:14:50 1:
2015.03.13 08:14:50 1: New entries in the CHANGED file:
2015.03.13 08:14:50 1: - bugfix: 57_CALVIEW: fixed commandref
2015.03.13 08:14:50 1: - feature: GUEST: added support for RESIDENTS toolkit
2015.03.13 08:14:50 1: - feature: ROOMMATE: added support for RESIDENTS toolkit
2015.03.13 08:14:50 1: - feature: RESIDENTS: added support for RESIDENTS toolkit
2015.03.13 08:14:50 1: - added: RESIDENTStk: new RESIDENTS toolkit and first function wakeuptimer
2015.03.13 08:14:50 1: Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while
2015.03.13 08:16:43 1: *** EN FHEM/11_OWX_DS2480.pm: No document text found
*** EN FHEM/11_OWX_Executor.pm: No document text found
*** EN FHEM/11_OWX_FRM.pm: No document text found
*** EN FHEM/11_OWX_SER.pm: No document text found
*** EN FHEM/99_UtilsLevelJet.pm: No document text found
*** EN FHEM/99_UtilsMaxScan.pm: No document text found
*** EN FHEM/99_myUtils.pm: No document text found
*** EN FHEM/99_myUtilsTM.pm: No document text found
*** EN FHEM/99_myUtilsTelefon.pm: No document text found
2015.03.13 08:16:43 1:
2015.03.13 08:16:43 1: update finished, "shutdown restart" is needed to activate the changes.
2015.03.13 08:16:43 1:
2015.03.13 08:16:43 1: Please consider using the global attribute sendStatistics
2015.03.13 08:16:48 1: 192.168.1.151:1000 disconnected, waiting to reappear (HMLAN1)
2015.03.13 08:16:48 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.03.13 08:16:49 1: 192.168.1.151:1000 reappeared (HMLAN1)
2015.03.13 08:16:49 1: HMLAN_Parse: HMLAN1 new condition init
2015.03.13 08:16:50 1: HMLAN_Parse: HMLAN1 new condition ok
2015.03.13 08:16:51 1: nothing to do...Gruss
Zitat von: cotecmania am 13 März 2015, 08:27:55
Bin also nicht alleine damit ...
Nein, bist Du nicht. Und das Problem ist auch nicht neu, das existiert seit vielen Monaten. Es fällt nur jetzt wieder vermehrt auf, weil seit kurzem die commandref lokal erzeugt wird und dieser Schritt relativ lange dauert.
Wie Du in Deinem Log erkennen kannst, wurde auch in diesem Fall das update zweimal ausgeführt:
Das erste Mal um 08:14:47 - das Update wurde komplett ausgeführt und mit der Meldung 08:16:43 bestätigt.
Danach wurde das Update aber
noch einmal gestartet, es war dann natürlich nichts mehr zu tun, was auch um 08:16:51 korrekt gemeldet wurde.
Du betrachtest also immer nur die Abschlußmeldung des zweiten Updates, obwohl die Erfolgsmeldung des ersten Updates bereits im Log steht.
Hi,
wenn das Problem so bekannt ist, dann wundert es mich nur dass H.König das nicht kennt ...
und im Januar gings bei mir definitiv noch ...
Bleibt das nun so ?
Gruss
Joe
Das Problem bestand auch im Januar schon, Du hast es bloß nicht bemerkt, weil die Auswirkungen nicht bei jedem Update auftreten.
Hi,
es wäre trotzdem schön, wenn das wieder funktionieren würde ;)
Gruss