update finished ??????

[Ellert]

... 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:

Code Auswählen Erweitern

sudo /etc/init.d/fhem stop
sudo /etc/init.d/fhem start

[krikan]

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?

[Hans Franz]

Hallo,
der System-Befehl liefert bei mir auch mit erfolgreichem Update -1.
Erst mit

Code Auswählen Erweitern

{`/usr/bin/perl ./contrib/commandref_join.pl`}
erfolgt eine Anzeige.

Gruß
Hans

[Tom111]

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.

[Tom111]

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

Code Auswählen Erweitern

update finished, "shutdown restart" is needed to activate the changes.

nur alle Updates die danach kamen, dann nicht mehr!

[krikan]

Hallo,
der System-Befehl liefert bei mir auch mit erfolgreichem Update -1.
Erst mit

Code Auswählen Erweitern

{`/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

[Tom111]

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

Events (Filter:global):
2015-08-08 09:35:40 Global global UPD FHEM/MaxCommon.pm
2015-08-08 09:35:40 Global global

[Jojo11]

Hallo,

habe das gleiche Phänomen seit Monaten auf meinem Cubietruck beobachtet.

schöne Grüße
Jo

[rudolfkoenig]

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

Code Auswählen Erweitern

  BlockingInformParent("Log", [$level, $text], 0);
durch

Code Auswählen Erweitern

  Log $level, $text;
ersetzen, "attr global mseclog" und "attr global verbose 5" setzen, das Problem "provozieren", und den Log-Ausschnitt hier anhaengen.

[Tom111]

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

[rudolfkoenig]

Ich sehe gerade, dass meine Zeile falsch war, und noch ein ueberfluessiges [ enthielt, das habe ich korrigiert. Richtig ist:

Code Auswählen Erweitern

Log $level, $text;
Kannst du es bitte erneut versuchen?

[Tom111]

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.

[rudolfkoenig]

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.

[Tom111]

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.

Falls das Problem zuverlaessig auftritt, dann bitte in FHEM/98_update.pm, in der Funktion update_Log2Event die Zeile

Code Auswählen Erweitern

  BlockingInformParent("Log", [$level, $text], 0);
durch

Code Auswählen Erweitern

  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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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 !!!!

Code Auswählen Erweitern

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

[rudolfkoenig]

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.