Also es ist schon sehr komisch, gestern wurde eine Datei geupdatet und der Prozess lief durch bis:
update finished, "shutdown restart" is needed to activate the changes.
alles ok.
Was mir aber schon öfters aufgefallen ist, dass "update finished, "shutdown restart" is needed to activate the changes."
nicht immer angezeigt wird.
Heute auch wieder, ich warte und warte aber nichts passiert, bis ich nach 10 min warten dann doch mal ein "shutdown restart" durchgeführt habe.
Also, wie soll ich mich verhalten, wie lange soll, muß, kann ich warten?
Wo kann der Fehler liegen (wenn es überhaupt ein Fehler ist)?
Gruß
Tom
Was sagt denn das Log; was wurde "upgedatet"?
Fehlt etwas?
Zitat von: krikan am 05 August 2015, 10:43:56
Was sagt denn das Log; was wurde "upgedatet"?
Fehlt etwas?
nicht was oder wieviel geupdatet wurde sondern wie lange ich nach dem Update warten soll ist die Frage.
Zitat von: Tom111 am 05 August 2015, 10:40:23
Wo kann der Fehler liegen (wenn es überhaupt ein Fehler ist)?
Na ja, dann hat wohl jemand Dein Post geändert. ;)
Ohne die Ursache zu kennen, kann man zur Zeit nichts konkretes sagen.
So wie ich das Update verstanden habe, ist ein shutdown restart nur notwendig, wenn die Datei fhem.pl durch das Update geändert wurde. Alles andere kann FHEM intern aktualisieren.
Gruß brogoss
Zitat von: brogoss am 05 August 2015, 13:12:47
So wie ich das Update verstanden habe, ist ein shutdown restart nur notwendig, wenn die Datei fhem.pl durch das Update geändert wurde. Alles andere kann FHEM intern aktualisieren.
Das stimmt so nicht. Es findet nur ein Download statt. Zur Aktivierung der erneuten Module ist mMn ein "shutdown restart" bzw. "reload" notwendig: http://www.fhemwiki.de/wiki/Update
also...
woran kann es liegen dass ich die folgende Meldung nicht mehr erhalte:
update finished, "shutdown restart" is needed to activate the changes.
Vermutlich bekommst du die Meldung nicht da das Update noch nicht fertig ist.
Ein Blick ins Log wird dir aber sicher weiterhelfen.
So, ich hab das System komplett neu aufgesetzt, an FHEM hab ich im Grunde nur die fhem.cfg geändert.
So sieht es heute aus :
Events (Filter:global):
2015-08-07 09:50:33 Global global UPD ./CHANGED
2015-08-07 09:50:34 Global global UPD FHEM/95_Dashboard.pm
2015-08-07 09:50:34 Global global
2015-08-07 09:50:34 Global global New entries in the CHANGED file:
2015-08-07 09:50:34 Global global - bugfix: 95_Dashboard: fixed problem with smallscreen styles that caused devices
2015-08-07 09:50:34 Global global to be shown in wrong tabs
2015-08-07 09:50:34 Global global Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while
nach 20 sec.:
2015-08-07 09:50:54 Global global
das wars, mehr kam nicht. :-\
Nochmal, das Problem tritt anscheinend nur bei dem Raspberry Pi 2B auf,
hier mal das Update bei einem Raspberry Pi B Rev.2
Events (Filter:global):
2015-08-07 10:14:20 Global global UPD ./CHANGED
2015-08-07 10:14:20 Global global UPD FHEM/95_Dashboard.pm
2015-08-07 10:14:21 Global global
2015-08-07 10:14:21 Global global New entries in the CHANGED file:
2015-08-07 10:14:22 Global global - bugfix: 95_Dashboard: fixed problem with smallscreen styles that caused devices
2015-08-07 10:14:22 Global global to be shown in wrong tabs
2015-08-07 10:14:23 Global global Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while
2015-08-07 10:16:58 Global global *** EN FHEM/11_OWX_DS2480.pm: No document text found
2015-08-07 10:16:58 Global global *** EN FHEM/11_OWX_Executor.pm: No document text found
2015-08-07 10:16:58 Global global *** EN FHEM/11_OWX_FRM.pm: No document text found
2015-08-07 10:16:59 Global global *** EN FHEM/11_OWX_SER.pm: No document text found
2015-08-07 10:16:59 Global global
2015-08-07 10:16:59 Global global update finished, "shutdown restart" is needed to activate the changes.
Wo muss ich ansetzen damit "update finished, "shutdown restart" is needed to activate the changes." auch bei dem Raspberry Pi 2B
angezeigt wird ?
Hat irgend jemand eine Idee ?
Tom111,
diese Diskussion (http://forum.fhem.de/index.php/topic,34450.0.html) hatten wir doch im März schon und Du warst maßgeblich darin "verwickelt" :o
Das neu Bauen der commandref dauert (wie die Meldung ja besagt) relativ lange. Wer das (mit den im verlinkten Thread aufgeführten Nachteilen) nicht möchte, kann commandref in das exclude_from_update (http://www.fhemwiki.de/wiki/Update) Attribut aufnehmen.
Peter
Zitat von: ph1959de am 07 August 2015, 11:11:52
Tom111,
diese Diskussion (http://forum.fhem.de/index.php/topic,34450.0.html) hatten wir doch im März schon und Du warst maßgeblich darin "verwickelt" :o
Damals ging es darum dass es, wie du auch sagst, relativ lange dauert.
Aber jetzt kommt die Meldung "
update finished, "shutdown restart" is needed to activate the changes." ja gar nicht mehr!!
Wie gesagt, das ist nur bei dem
Raspberry Pi 2B so.
Wird die Commandref auf dem Raspi ohne Abschlussmeldung denn (vollständig) neu generiert? Ausbleiben der Nachricht bedeutet mMn eigentlich, dass der Raspi mit commandref_join.pl noch nicht fertig ist.
Du konntest auch mal manuell aus der Fhem-Kommandzeile aufrufen und auf Probleme/Fehler beobachten:
{system("/usr/bin/perl ./contrib/commandref_join.pl")}
Achtung: Wenn Du vor Abschluss der Generierung ein "shutdown restart" machst, überlebt der commandref_join.pl-Perlprozeß auf meinem Raspi und generiert die Commandref zu Ende.
10 min Dauer auf einem Raspi können auch vorkommen, wenn Du den entsprechend auslastet.
Zitat von: krikan am 07 August 2015, 11:32:21
Wird die Commandref auf dem Raspi ohne Abschlussmeldung denn (vollständig) neu generiert? Ausbleiben der Nachricht bedeutet mMn eigentlich, dass der Raspi mit commandref_join.pl noch nicht fertig ist.
Du konntest auch mal manuell aus der Fhem-Kommandzeile aufrufen und auf Probleme/Fehler beobachten:
{system("/usr/bin/perl ./contrib/commandref_join.pl")}
Achtung: Wenn Du vor Abschluss der Generierung ein "shutdown restart" machst, überlebt der commandref_join.pl-Perlprozeß auf meinem Raspi und generiert die Commandref zu Ende.
10 min Dauer auf einem Raspi können auch vorkommen, wenn Du den entsprechend auslastet.
nach Eingabe von :
{system("/usr/bin/perl ./contrib/commandref_join.pl")}kommt als Antwort:
-1Der Raspberry Pi
2B scheint sich in Hinsicht auf FHEM anders zu verhalten als der Raspberry Pi
B mir sind auch noch andere Sachen aufgefallen die ich mir nicht erklären kann.
Sorry aber so pauschal kann das ja schon per se nicht stimmen.
Nur weil es bei DIR nicht geht heisst das ja noch lange nicht das es Allgemein so ist.
Meine RasPi - einmal ein PasPi 2B und ein RasPi B - lassen FHEM ohne Probleme updaten.
Manchmal dauert es am B etwas länger aber nach gut 3-5 Minuten ist auch er mit allem fertig und erwartet einen FHEM-Neustart.
Zitat... wie lange ich nach dem Update warten soll ist die Frage.
Wenn ich wissen möchte ob der Update Prozess durchgelaufen ist und mein Browser nicht mehr geöffnet ist, dann nutze ich den ssh Zugang meines RasPi B+ und den Befehl top. Damit erscheint eine Prozessliste.
Da zum Updaten eine 2. FHEM-Instanz gestartet wird, mit hoher Prozessauslastung (beim B+ um die 70%, beim 2B sicherlich weniger), kann ich am Fehlen der 2. Instanz sehen ob das Update abgeschlossen wurde.
Von der Befehlszeile aus starte ich fhem dann auch gleich neu, mit:
sudo /etc/init.d/fhem stop
sudo /etc/init.d/fhem start
Der Rückgabewert -1 beim Perl system()-Befehl heißt nichts anderes als Fehler bei Ausführung des system()-Befehls.
Der Aufruf von commandref_join.pl läuft also bei Dir wohl nicht korrekt. Deine commandref wird vermutlich nicht bzw. nicht vernünftig neu generiert.
Schau mal, ob die Rechte für Fhem korrekt gesetzt sind?
Ist die Installation vollständig?
Hallo,
der System-Befehl liefert bei mir auch mit erfolgreichem Update -1.
Erst mit
{`/usr/bin/perl ./contrib/commandref_join.pl`}
erfolgt eine Anzeige.
Gruß
Hans
Zitat von: krikan am 07 August 2015, 19:04:31
Der Rückgabewert -1 beim Perl system()-Befehl heißt nichts anderes als Fehler bei Ausführung des system()-Befehls.
Der Aufruf von commandref_join.pl läuft also bei Dir wohl nicht korrekt. Deine commandref wird vermutlich nicht bzw. nicht vernünftig neu generiert.
Schau mal, ob die Rechte für Fhem korrekt gesetzt sind?
Ist die Installation vollständig?
Danke für deine Antwort!
Also wenn das so ist und es wirklich ein Rechte-Fehler ist dann bin ich ja schon mal viel weiter.
Jetzt stellt sich nur die Frage wo muss ich welche Rechte haben oder anders welche Datei bzw. Ordner hat die falschen Rechte ?
Ich kann ja mal versuchen FHEM in
sudoers root-Rechte zu geben und dann ein Update laufen lassen, kann das ja mal morgen um 8:00 Uhr
versuchen ob es dann klappt, zumindest hätte ich dann die Gewissheit dass es an den Rechten liegt!
Die Installation an sich scheint soviel ich seh vollständig zu sein, mit Gewissheit kann ich das aber nicht sagen.
Zitat von: Puschel74 am 07 August 2015, 18:12:42
Sorry aber so pauschal kann das ja schon per se nicht stimmen.
Nur weil es bei DIR nicht geht heisst das ja noch lange nicht das es Allgemein so ist.
Meine RasPi - einmal ein PasPi 2B und ein RasPi B - lassen FHEM ohne Probleme updaten.
Manchmal dauert es am B etwas länger aber nach gut 3-5 Minuten ist auch er mit allem fertig und erwartet einen FHEM-Neustart.
Naja, an meinem
B Rev.2 klappt das ja auch, nur nicht bei dem
2B und ich habe extra darauf geachtet dass FHEM so sauber wie möglich installiert wird. Das erste Update was FHEM gezogen hat war ja dann das komplette Filesystem, dieses ist durchgelaufen mit
update finished, "shutdown restart" is needed to activate the changes.nur alle Updates die danach kamen, dann nicht mehr!
Zitat von: Hans Franz am 07 August 2015, 20:07:43
Hallo,
der System-Befehl liefert bei mir auch mit erfolgreichem Update -1.
Erst mit
{`/usr/bin/perl ./contrib/commandref_join.pl`}
erfolgt eine Anzeige.
Gruß
Hans
Jetzt wird es spannend und Du hast Recht das Modul nutzt `` statt system(). Mein Fehler nicht vernünftig in den Code geschaut zu haben.
Bei mir läuft das aber mit dem system-Befehl und `` sauber durch.
Ich glaube wir brauchen Hilfe von einem Perl/Linux-Experten.
Bzgl. von mir in den Raum geworfener Rechte:
Group: dialout
Owner:fhem
so, da es heute keine Updates gab, habe ich in der Datei MaxCommon.pm eine Änderung vorgenommen und danach ein Update durchgeführt.
Hier das Ergebnis bei dem Raspberry B Rev.2
Events (Filter:global):
2015-08-08 09:33:29 Global global RMDIR: ./restoreDir/2015-08-05
2015-08-08 09:33:30 Global global UPD FHEM/MaxCommon.pm
2015-08-08 09:33:30 Global global
2015-08-08 09:33:30 Global global update finished, "shutdown restart" is needed to activate the changes.
und hier der Raspberry 2B
Events (Filter:global):
2015-08-08 09:35:40 Global global UPD FHEM/MaxCommon.pm
2015-08-08 09:35:40 Global global
Hallo,
habe das gleiche Phänomen seit Monaten auf meinem Cubietruck beobachtet.
schöne Grüße
Jo
Von diesem Problem habe ich auch schon gehoert, leider kann ich es nicht nachstellen.
Konkret: ab einem bestimmten Punkt werden vom update keine Meldungen mehr geloggt/angezeigt. Voraussetzung ist, dass update im Hintergrund laeuft.
Wenn update im Hintergrund laeuft (Voreinstellung), dann wird im Hintergrund-Prozess die Funktion Log durch update_Log2Event ersetzt, was im Hauptprozess zusaetzlich ein "trigger global Nachricht-Text" ausfuehrt. Evtl. bricht die Verbindung zum Hauptprozess ab.
Falls das Problem zuverlaessig auftritt, dann bitte in FHEM/98_update.pm, in der Funktion update_Log2Event die Zeile
BlockingInformParent("Log", [$level, $text], 0);
durch
Log $level, $text;
ersetzen, "attr global mseclog" und "attr global verbose 5" setzen, das Problem "provozieren", und den Log-Ausschnitt hier anhaengen.
Hallo Rudi,
es ist zum verzweifeln, nur zur Info, ich habe FHEM auch bereits mit root-Rechten Laufen lassen und das Update probiert, mit dem selben Ergebnis.
Zu deiner Vorgehensweise:
1.) ich habe in 98_update.pm deine Änderung durchgeführt und eine Datei (hier habe ich einfach mal MaxCommon.pm genommen) geändert um ein Update zu provozieren.
2.) in der fhem.cfg habe ich "attr global mseclog" und "attr global verbose 5" gesetzt.
3.) FHEM "shutdown restart"
4.) update - Update schlug fehl mit dem Kommentar Unknown command update, try help.
5.) "attr global mseclog" und "attr global verbose 5" wieder auf Standard gesetzt
6.) Änderung in 98_update.pm wieder rückgängig gemacht.
7.) FHEM "shutdown restart"
Als Anhang habe ich die Datei fhem-2015-08.log hochgeladen.
Es sind ziemlich viele Daten, ich hoffe du kannst damit was anfangen.
Gruß
Tom
Ich sehe gerade, dass meine Zeile falsch war, und noch ein ueberfluessiges [ enthielt, das habe ich korrigiert. Richtig ist:
Log $level, $text;
Kannst du es bitte erneut versuchen?
so, das ganze habe ich nochmal durchlaufen lassen, diesmal (mit Log $level, $text; ) bekomme ich auch die Rückmeldung
Global global update finished, "shutdown restart" is needed to activate the changes.
Als Anhang hab ich die Datei fhem-2015-08.log hochgeladen.
1. Mein Vorschlag mit Log einfuegen ist sinnlos (hoffentlich liegts an der Hitze, es bewirkt einen rekursiven Aufruf)
2. Du hast die bemaengelte Zeile offenbar (jedenfalls laut Log) nicht auskommentiert oder eine nicht auskommentierte Version verwendet, damit bleibt alles beim Alten.
3. Da das Problem offenbar nicht auftritt, koennen wir es nicht debuggen. Das Problem waere auch in der modifizierten Form sichtbar: "update finished" erscheint nicht auf dem Bildschirm.
4. Nach etwas Nachdenken sollte mir auch reichen das Problem mit den zwei gesetzten Attributen, ohne irgendwelche Dateiaenderung zu provozieren.
Hallo Rudi,
ich kann natürlich nur das versuchen was man mir vorgibt was ich tun soll, du kannst mir glauben, dass ich mich genau an deine Anweisung gehalten habe.
Zitat von: rudolfkoenig am 08 August 2015, 14:42:05
Falls das Problem zuverlaessig auftritt, dann bitte in FHEM/98_update.pm, in der Funktion update_Log2Event die Zeile
BlockingInformParent("Log", [$level, $text], 0);
durch
Log $level, $text;
ersetzen, "attr global mseclog" und "attr global verbose 5" setzen, das Problem "provozieren", und den Log-Ausschnitt hier anhaengen.
Ich habe aber noch etwas herausgefunden und zwar....
wenn ich innerhalb des FHEM-Ordners eine Datei update die mit zwei Zahlen beginnt, also z.B
00_MQTT.pm, dann bekomme ich auch
die Meldung
Global global update finished, "shutdown restart" is needed to activate the changes..
Bei einer Datei wie z.B.
SHC_parser.pm erhalte ich diese Meldung nicht.
Ich habe nun mehrere Versuche durchgeführt, hier das Ergebnis:
98_update.pm geändert, Ergebnis:Events (Filter:global):
2015-08-08 17:25:04 Global global UPD FHEM/98_update.pm
2015-08-08 17:25:04 Global global Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while
2015-08-08 17:25:24 Global global
2015-08-08 17:25:24 Global global update finished, "shutdown restart" is needed to activate the changes.
MaxCommon.pm geändert, Ergebnis:
Events (Filter:global):
2015-08-08 17:28:39 Global global UPD FHEM/MaxCommon.pm
2015-08-08 17:28:39 Global global 00_MQTT.pm geändert, Ergebnis:Events (Filter:global):
2015-08-08 17:30:50 Global global UPD FHEM/00_MQTT.pm
2015-08-08 17:30:50 Global global Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while
2015-08-08 17:31:11 Global global
2015-08-08 17:31:11 Global global update finished, "shutdown restart" is needed to activate the changes.SHC_parser.pm geändert, Ergebnis:Events (Filter:global):
2015-08-08 17:32:29 Global global UPD FHEM/SHC_parser.pm
2015-08-08 17:32:30 Global global 98_HourCounter.pm geändert, Ergebnis:Events (Filter:global):
2015-08-08 17:33:50 Global global UPD FHEM/98_HourCounter.pm
2015-08-08 17:33:50 Global global Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while
2015-08-08 17:34:11 Global global
2015-08-08 17:34:11 Global global update finished, "shutdown restart" is needed to activate the changes.Und jetzt kommt´s .........98_weblink.pm UND SubProcess.pm geändert !!!!Events (Filter:global):
2015-08-08 17:45:55 Global global UPD FHEM/98_weblink.pm
2015-08-08 17:45:55 Global global UPD FHEM/SubProcess.pm
2015-08-08 17:45:55 Global global Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while
2015-08-08 17:46:15 Global global Ich hoffe du kannst daraus irgendetwas konkludieren.
Gruß
Tom
Nette Beobachtung, ich kann es leider weder Nachstellen, noch aus dem Code einen Sonderfall dafuer ablesen.
Da du damit aber scheinbar eine sichere Methode hast das Problem zu reproduzieren, kannst du mir mein log mit den zwei Attributen erstellen.
ja, kann ich machen,
soll ich
BlockingInformParent("Log", [$level, $text], 0);
wieder gegen
Log $level, $text;
tauschen ?
Da du ja letztens gemeckert hast, soll ich nach der Änderung die Datei vom Update ausschließen ?
attr global exclude_from_update 98_update.pm
und dann erst das Update ziehen ?
=========================================================================
Info, das Update heute lief ohne Probleme durch :
2015.08.09 11:37:35 1: UPD ./CHANGED
2015.08.09 11:37:35 1: UPD FHEM/00_ZWDongle.pm
2015.08.09 11:37:35 1: UPD FHEM/01_FHEMWEB.pm
2015.08.09 11:37:35 1: UPD FHEM/10_ZWave.pm
2015.08.09 11:37:35 1: UPD FHEM/57_Calendar.pm
2015.08.09 11:37:35 1: UPD FHEM/93_FHEM2FHEM.pm
2015.08.09 11:37:35 1: UPD FHEM/95_Dashboard.pm
2015.08.09 11:37:36 1: UPD FHEM/firmware/JeeLink_LaCrosse.hex
2015.08.09 11:37:36 1: UPD www/pgm2/fhemweb.js
2015.08.09 11:37:36 1:
2015.08.09 11:37:36 1: New entries in the CHANGED file:
2015.08.09 11:37:36 1: - bugfix: 95_Dashboard: fixed issue with disappearing menu and command input in
2015.08.09 11:37:36 1: room "Everything"
2015.08.09 11:37:36 1: - feature: 57_Calendar: made download from URL non-blocking
2015.08.09 11:37:36 1: Calling /usr/bin/perl ./contrib/commandref_join.pl, this may take a while
2015.08.09 11:37:58 1:
2015.08.09 11:37:58 1: update finished, "shutdown restart" is needed to activate the changes.
waren ja auch alles nur Dateien die mit einer Zahl anfangen im Ordner FHEM zum Austausch.
Nein, tauschen brauchst du nicht, wie gestern geschrieben, war mein Vorschlag eh sinnlos.
Nur die Attribute haette ich gerne.
ok, habe das Update der beiden Datein 98_weblink.pm und SubProcess.pm provoziert und die Attribute
attr global verbose 5
attr global mseclog
gesetzt.
Hier nun das Log nach dem Update:
Sorry, ich finde dein Log nicht.