[ERLEDIGT] seit heute (14.4.20) nach update restarted fhem dauernd

[Otto123]

Ich bin mir ja sicher, das die Probleme schnell behoben werden. Bis dahin:
Es gibt einen Artikel update im Wiki.
Im letzten Abschnitt ist kurz und knapp erklärt was man tun kann wenn es schief gegangen ist. Ja es ist mit manuellen Eingaben verbunden und geht nicht nur mit klicken...
Aber es ist genauso leicht und genauso schwer wie update zu machen.

Das restore sollte der Standardvorgang und Empfehlung bei solchen Problemen sein die durch ein Update hervorgerufen werden.
Die Empfehlung dem User die Programmiererschuhe zu empfehlen halte ich für falsch. 
Sollte FHEM nach einem update auf Grund eines groben Fehlers nicht mehr starten, kann das restore auch auf System Ebene durchgeführt werden. Ein Ansatz gibt es in dem Artikel. Ich werde das mal noch analog im update Artikel unterbringen. Edit: getan

Gruß Otto

[CoolTux]

So Ihr dürft nun noch mal Update anstoßen. Dann sollte alles wieder gehen.

[herrmannj]

Hier zeigen sich eher die Schwächen von FHEM, die Richard kritisiert, alles ist von allem abhängig. Wenn ein einziges Modul abstürzt, läuft das ganze System nachher nicht mehr.

Dieser Aussage würde ich jetzt insofern widersprechen dass dies für die meisten Systeme zutrifft. Kernel-Treiber können ein os zum Absturz bringen usw.

Man kann jetzt auch argumentieren dass es bisher ja anstandslos lief. Es ist also (scheinbar, ich will da nichts falsches sagen) nicht so dass die Änderung einen Bug zum Vorschein gebracht hat, die Änderung hat den Bug verursacht.

Nichts desto trotz bin ich dafür dass Ordnung herrscht und use strict plus use warnings gehören da rein! Dadurch findet man dann auch besser echte Bugs. Hier ist es blöd gelaufen, wird beseitigt und dann ist es besser als vorher was vmtl im Interesse aller ist

[Beta-User]

(...mei, hier ist was los, bin zu langsam...)

@Otto:
Auch wenn betateilchen Wiki-Artikel nicht besonders schätzt: Vielleicht bringst du irgendwo noch einen Hinweis auf [configDB] FHEM im rescue-Modus starten unter?

Und evtl. wäre es auch eine Idee, für die "text-cfg-user" sowas wie eine "Minimal-FHEM-cfg" zu empfehlen, mit der man dann ggf. ein update machen kann, oder, wenn es noch eiliger ist direkt ein svn-update (mit dem Svn_GetFile()), damit es gleich auch mit den Rechten paßt):

Code Auswählen Erweitern

{ Svn_GetFile("FHEM/DevIo.pm", "FHEM/DevIo.pm",  }

Solche Probleme sind ja in der Regel schnell und zentral gelöst (oder hier besser: Die Symptome sind abgestellt).

[CoolTux]

Dieser Aussage würde ich jetzt insofern widersprechen dass dies für die meisten Systeme zutrifft. Kernel-Treiber können ein os zum Absturz bringen usw.

Man kann jetzt auch argumentieren dass es bisher ja anstandslos lief. Es ist also (scheinbar, ich will da nichts falsches sagen) nicht so dass die Änderung einen Bug zum Vorschein gebracht hat, die Änderung hat den Bug verursacht.

Nichts desto trotz bin ich dafür dass Ordnung herrscht und use strict plus use warnings gehören da rein! Dadurch findet man dann auch besser echte Bugs. Hier ist es blöd gelaufen, wird beseitigt und dann ist es besser als vorher was vmtl im Interesse aller ist

Das sehe ich ganz anders Jörg. Die Änderungen hat schon einen Bug hervorgebracht.
Wenn eine Routine als Übergabe eine Hash Referenz erwartet aber die Module welche diese Routine aufrufen einen String übergeben dann machen die Module etwas falsch. Das ist ein Bug in den Modulen.
Nachtrag: Es wird hier in der Tat nichts erwartet. Dennoch erfolgt mit $callback ein symbolischer Funktionsaufruf und wenn $callback keine Code Referenz ist dann bekommt man die Meldung.

Alternativ kann man eine Prüfung in DevIO einbauen und einen Warnung aussprechen. Ich werde da heute einen Patchvorschlag bringen. Mal schauen ob der Anklang findet.


Grüße

[the ratman]

So Ihr dürft nun noch mal Update anstoßen. Dann sollte alles wieder gehen.

jau, scheint wieder zu funzen. thx!

hab hier mal erledigt gemacht.
bitte wo weiterstreiten, wo ichs ned lesen muß - danke!

[enno]

großes problem!. hab mein tägliches update gemacht, seit dem startet fhem in nem loop.

Moin,

warum machst du jeden Tag ein Update? Hast du Angst etwas zu verpassen? Oder liebst du das Risiko? Würde ein wöchentliches oder monatliches Update im Normalfall nicht schon ausreichen?


Gruss
  Enno

[the ratman]

weil die 1. frage bei problemen is: "hast du ein aktuelles fhem?"

und wieso nicht? ich bin ja gern betatester - meist ohne ahnung, aber betatester *g*
ausserdem ändert "nix updaten" nix an den problemen im code.

[enno]

weil die 1. frage bei problemen is: "hast du ein aktuelles fhem?"

und wieso nicht? ich bin ja gern betatester - meist ohne ahnung, aber betatester *g*

bei täglichen Update würde ich dich schon zu alpha-tester rechnen Aber ich danke dir trotzdem für deinen "Mut", da ich vor meinen Updates immer im Forum nach solchen Einträgen wie deinem hier schaue und dann mit dem Update ggf. etwas warte. Damit bin ich bisher um Komplettausfälle fast herum gekommen. Ok, als am Homematic Modul rumgeschraubt wurde hatte es mich auch kräftig erwischt...

Gruss
  Enno

[rudolfkoenig]

Wenn eine Routine als Übergabe eine Hash Referenz erwartet aber die Module welche diese Routine aufrufen einen String übergeben dann machen die Module etwas falsch. Das ist ein Bug in den Modulen.

Die Methode hat weder das Eine, noch das Andere zugesichert, ohne use strict hat beides funktioniert, deswegen sehe ich die Module auch nicht als fehlerhaft.

Ich bin noch nicht ueberzeugt dass man Funktionsnamen als Callback verbieten solltem Immerhin koennen dann Dienste wie "fhemdebug timerList" was Lesbares ausgeben. Die Vorteile einer Einschraenkung (nur Funktionszeiger zuzulassen) habe ich noch icht entdeckt.

[the ratman]

@enno

mut braucht man ned, nur ein bissi blödheit - und davon hab ich mehr als genug.

aber im ernst: ich mach das jetzt seit jahren so. und wenns den mal ein problem gibt, meld ichs hier und spiel die alten sachen derweil zurück. meistens kann ich mir ja mittlerweile sogar als user denken, an welchem file es liegt und gleich mal den richtigen anschreiben. diesmal war ich etwas mehr verwirrt als sonst *g*.

das melden ist eh meine einzige art, wie ich was zu fhem beitragen kann - somit tuts mir auch ned weh, 1 min. mehr aufwand für das anstarten von winscp und das rückspielen der alten files aufzuwenden.
ich profitier ja dann davon auch gewaltig, wie man hier gerade sieht.

[herrmannj]

Die Methode hat weder das Eine, noch das Andere zugesichert, ohne use strict hat beides funktioniert, deswegen sehe ich die Module auch nicht als fehlerhaft.

Ich bin noch nicht ueberzeugt dass man Funktionsnamen als Callback verbieten solltem Immerhin koennen dann Dienste wie "fhemdebug timerList" was Lesbares ausgeben. Die Vorteile einer Einschraenkung (nur Funktionszeiger zuzulassen) habe ich noch icht entdeckt.

Das sehe ich ganz genau so, volle Zustimmung.

[Christoph Morrison]

Und: wie soll das verhindert werden!?

Ein erster Schritt wäre es, die User nicht dazu zu zwingen, ihre Updates aus einem Unstable-Zweig machen zu müssen, genauso wenig wie man sie zwingen sollte, eine Neuinstallation aus einem Unstable-Zweig machen zu müssen (deb) oder eine wirklich krass veralterte Version zu bekommen (FHEM "6.0" vom 2020-01-26).

Der nächste Schritt wären automatisierte Integrations- und Regressionstests für Sachen die aus unstable nach stable wollen.

Aktuell wird die Endbenutzerbasis für diese Tests missbraucht, da hat ratman durchaus recht. Es ist eine Schande, wirklich eine Schande, dass ein User ein Update unterlassen soll, weil man ja eh nie weiß, ob das System danach noch funktioniert. Aber es ist aktuell die bessere Wahl.

Traurig genug übrigens, dass Richard, der hier die Mistarbeit macht, die jahrelang mutwillig und gegen Warnungen unterlassen wurde, nun als "Richard der Erste" und schlimmeres verunglimpft wird.

[rudolfkoenig]

Der nächste Schritt wären automatisierte Integrations- und Regressionstests für Sachen die aus unstable nach stable wollen.

Ich gehe davon aus, dass das aktuelle Problem damit nicht entdeckt gewesen waere, weil die besagte Zeile nur dann aufgerufen wird, falls die Verbindung mit der externen Schnittstelle hergestellt wurde. Und ich habe gerade Schwierigkeiten ein Testsystem vorzustellen, an dem alle von FHEM unterstuetzte Geraete angeschlossen sind.

[the ratman]

bitte leute - is ja alles in ordnung - wir haben wieder was neues erfahren ... vielleicht will ja wer draus lernen?


ansonsten: enduser haben auch nix davon, wenn jetzt in gefühlt jedem fred immer das (aus enduser-sicht) gleiche diskutiert wird.

wärs da nicht besser, ihr devs würdets euch alle mal ein bissi deeskalieren, euch in einem dev-forum zusammensetzen und für einen klaren weg sorgen? machts ne umfrage unter euch, wer was will und entscheidets dann. oder was weiß ich ...
diese ewige streiterei, was warum und aus welcher sicht am besten wäre bringt euch doch eh nix ... naja, ausser böses blut und verhärtete fronten am ende.

somit die bitte eines users: kriegts euch mal alle wieder ein, atmets mal tief durch und redets dann in ruhe drüber, wo fhem hin soll.
vielen dank im voraus an alle devs!