update.pm - Module reload vs. FHEM Neustart

[Markus Bloch]

Hallo zusammen,

ich habe in letzter Zeit immer jeden Tag einmal ein update von FHEM durchgeführt und mir ist nach diesem Update sehr oft FHEM abgestürzt, weil irgendwelche Probleme in Modulen auftraten (z.B. Too Many arguments, usw.). Der Grund war jedesmal, das neue Module nur mit einen Reload eingebunden werden.

Hier seh ich allerdings die Gefahr, dass z.T. neue Module (je nach dem) nicht mit den alten Datenstrukturen bzw. laufenden InternalTimers richtig klarkommen und daher crashen.

Ich würde daher vorschlagen nach jedem update automatisch ein shutdown restart durchzuführen um mit den neuen Modulen auch mit einem sauberen Device-Hash beginnen zu können.

Was meint ihr dazu?

Gruß

Markus 

[Rudolf Koenig]

> Was meint ihr dazu?

Ich will mich dem "immer Neustart" Version ganz verschliessen, obwohl ich es
etwas schade finde, den Feature "update ohne Neustart" aufzugeben.

Hat irgendjemand eine Idee, wie man bei Laden mancher Module das umgehen
koennte?

Ansonsten waere es an Martin zu entscheiden, als Autor vom update.

[Markus Bloch]

Hat irgendjemand eine Idee, wie man bei Laden mancher Module das umgehen
koennte?

Wie währe es, nach dem Module-Reload, alle Devices, deren Modul-File geupdatet wurde mit einem erneuten "define" wieder neu aufzubauen + die devicespezifischen werte aus dem fhem-statefile zu setzen?

Gruß
Markus

[Martin Fischer]

nunja... trotz das ich der derzeitige maintainer von update bin, denke ich das
ich dieseentscheidung nicht alleine treffe werde.

aus meiner sicht möchte ich auf eine neustart verzichten, wenn möglich. so wie
es übrigens auch vorher war.

wenn ich nun ein neustart "erzwingen" würde, dann beseitigen wir aus meiner
sicht nicht die ursache.. das klingt für mich so nach windows.. sorry für die
anmerkung ;-)

auch ich habe gerade heute zum zweiten mal in einen crash nach einem update
gelaufen:

2012.11.19 14:31:04 1: update 6 file(s) have been updated.
2012.11.19 14:31:04 1: reload: Error:Modul 01_FHEMWEB deactivated:
Too many arguments for main::FW_fC at /usr/share/fhem/FHEM/01_FHEMWEB.pm line 495, near "$cmddev) "

2012.11.19 14:31:04 1: reload: Error:Modul 10_CUL_HM deactivated:
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 572, near ""++803F$id${src}0204$s2000")"
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 827, near ""0101${state}00")"
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 885, near "))"
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 929, near ""8002$id$src${chn}00")"
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 962, near ""00")
"
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 1031, near ""00")"
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 1039, near ""00")"
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 1048, near ""00") # Send Ack
"
BEGIN not safe after errors--compilation aborted at /usr/share/fhem/FHEM/10_CUL_HM.pm line 1645.

2012.11.19 14:31:04 1: update reloaded module: 59_Weather
2012.11.19 14:31:04 1: update reloaded module: 98_weblink

selbiges hatte ich vor ca. zwei tagen:
Module(s) reloaded:
==> 00_HMLAN
==> 10_CUL_HM:
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 572, near ""++803F$id${src}0204$s2000")"
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 826, near ""0101${state}00")"
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 884, near "))"
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 928, near ""8002$id$src${chn}00")"
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 961, near ""00")
"
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 1030, near ""00")"
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 1038, near ""00")"
Not enough arguments for main::CUL_HM_SendCmd at /usr/share/fhem/FHEM/10_CUL_HM.pm line 1047, near ""00") # Send Ack
"
BEGIN not safe after errors--compilation aborted at /usr/share/fhem/FHEM/10_CUL_HM.pm line 1656.

==> 98_XmlList

Update completed!

hier liegt offensichtlich ein problem mit dem modul 10_CUL_HM.pm vor,
das vorangig behoben werden sollte.

es ist übrigens reproduzierbar.

gruss

[Rudolf Koenig]

> Wie w�hre es, nach dem Module-Reload, alle Devices, deren Modul-File

> geupdatet wurde mit einem erneuten "define" wieder neu aufzubauen + die
> devicespezifischen werte aus dem fhem-statefile zu setzen?

Das wuerde nicht helfen, und ich meine das Problem ist ein perl "bug": wenn man
per eval bzw. do eine Funktion ueberschreibt (das passiert beim reload), dann
werden zur Pruefung der Funktionsparameter die "alten" Definitionen benutzt.
Wenn diese nicht mit den neuen uebereinstimmen, dann vergisst perl alle die
beim eval ueberschriebenen Funktionen, auch die, die unveraendert waren.

D.h. nach Aendern der Parametersignatur fuehrt ein reload zum Entfernen aller
Funktionen dieses Moduls.

Aus diesem Grund tendiere ich dazu, reload aus update auszubauen, es sei denn
jemand hat eine rettende Idee.

[Martin Fischer]

Am Montag, 19. November 2012, 18:31:46 schrieb Rudolf Koenig:
> [...]

> Aus diesem Grund tendiere ich dazu, reload aus update auszubauen, es sei
> denn jemand hat eine rettende Idee.

eine "rettende idee" habe ich _noch_ nicht aber ich stelle mir die frage,
warum es bisher _immer_ ohne probleme ging.

im moment kann ich nicht glauben, das der fehler einfach so "unauffällig"
vorhanden war und keinem aufgefallen ist. ich arbeite bei der entwicklung ja
auch permanent mit reload. das fhem crasht kann ich nur hervorrufen, wenn ich
wirklich mist gebaut und irgendwas vergessen habe.

ich empfehle daher erstmal martin bei der fehlersuche zu unterstützen. wenn
wir was finden sollten, testen und dann kann man _immernoch_ überlegen ob das
reload aus update rausfliegt.

gruss

[Martin Fischer]

Am Montag, 19. November 2012, 18:31:46 schrieb Rudolf Koenig:
> [...]

> Aus diesem Grund tendiere ich dazu, reload aus update auszubauen, es sei
> denn jemand hat eine rettende Idee.

nachtrag um nochmal in der wunde zu bohren:

eine saubere trennung von stable zu development würde die zur zeit sehr
vielen, fast täglichen neuerungen / veränderungen etwas mehr ins ruhigere
fahrwasser bringen, so dass martin sich mehr auf das coden kümmern kann
anstatt nebenbei noch "ungelegte eier" supporten muss...

_jeder_ (ja, ich weiss: keiner wird gezwungen!) der zur zeit ein update macht,
ist dieser entwicklung ausgesetzt. ob er es nun will oder nicht.

sorry... ich vergass, das wir das thema begraben hatten ;-)

[Rudolf Koenig]

> ich empfehle daher erstmal martin bei der fehlersuche zu unterst�tzen.

Du darfst mich auch gleich mitunterstuetzen, da 01_FHEMWEB.pm hat das gleiche
Problem, und ich keine Ideen zum fixen :)

[Rudolf Koenig]

> sorry... ich vergass, das wir das thema begraben hatten ;-)

Stimmt, zusammen mit meinen Argumenten.

[Martin Fischer]

Am Montag, 19. November 2012, 18:49:49 schrieb Rudolf Koenig:
> > ich empfehle daher erstmal martin bei der fehlersuche zu unterstützen.

>
> Du darfst mich auch gleich mitunterstuetzen, da 01_FHEMWEB.pm hat das
> gleiche Problem, und ich keine Ideen zum fixen :)

rofl.. :-)

wenn ich eine idee hätte, ja dann würde ich sie hier zum verkauf anbieten :-)

spass beseite:
es tritt ja erst jetzt seit zwei / drei tagen auf. was waren den die
"gravierenden" änderungen, die nun dazu führen?

gruss

[Martin Fischer]

Am Montag, 19. November 2012, 19:17:53 schrieb Rudolf Koenig:
> > sorry... ich vergass, das wir das thema begraben hatten ;-)
>
> Stimmt, zusammen mit meinen Argumenten.

so langsam solltest du mich doch kennen ;-)

mühsam ernährt sich das eichhörnchen...