Autor Thema: fhem shutdown mit verzögerung  (Gelesen 796 mal)

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18657
fhem shutdown mit verzögerung
« am: 13 Januar 2019, 19:40:35 »
für das alexa modul das jetzt live ist haben wir ja einen autostart über fhem eingebaut.

das funktioniert so weit sehr gut und zuverlässig. an zwei stellen gibt es aber noch etwas nachbesserung bedarf.

grund dafür ist das alexa-fhem einen augenblick braucht um ordentlich runterzufahren statt sich einfach zu beenden.
deshalb wird erst ein SIGTERM geschickt und gewartet bis alles beendet ist. wenn das nicht innerhalb von 5 sekunden geschieht gibt es ein SIGkILL und auch dann muss noch ein klein wenig aufgeräumt werden. das ganze geschieht asynchron.

das ist bei delete, rereadcfg und shutdown ein problem.

für delete habe ich es jetzt so implementiert:
 - der anweder lässt das delete aus
 - er bekommt eine meldung das alexa-fhem beendet wird und danach das delete tatsächlich ausgeführt wird
 - nach dem beenden von alexa-fhem wird das delete ausgeführt.
das funktioniert bei einem manuellen delete wunderbar.

bei einem rereadcfg leider nicht. da wird im hintergrund beendet, aber fhem löscht die devices trotz rückmeldung, liest neu ein und legt an. dann kommt irgendwann das delete und das device ist weg. was so nicht beabsichtig war.
es gibt zwar eine meldung im log das was nicht stimmt, aber es ist unschön. könnte ich aber mit leben. ich mag rereadcfg sowieso nicht...

das größere problem ist aber shutdown. hier kann ein modul den shutdown nicht verzögern oder asynchron machen.
es wäre schön wenn die ShutdownFn zurückmelden könnte wenn alles erledigt ist und der shutdown tatsächlich erfolgen kann.

es gibt inzwischen noch zwei andere module die einen ähnlichen autostart wünschen und von einem verzögerten runter fahren profitieren würden. das gleiche gilt für alles was im hintergrund über blockig gestartet wurde.

wie schaut die meinung hierzu aus?


ps: ich versuche das starten und stoppen eines prozesses aus fhem in den drei modulen dann in etwas wiederverwendbares auszulagern. vermutlich gibt es noch andere anwender dafür.

FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2631
    • HMCCU
Antw:fhem shutdown mit verzögerung
« Antwort #1 am: 13 Januar 2019, 19:52:26 »
Für HMCCU wäre ein verzögerter Shutdown auch hilfreich. Das Abmelden der RPC Server von der CCU dauert mitunter auch ein paar Millisekunden länger als der Shutdown.
Die Frage ist, wie lange soll FHEM warten. Endlos wäre vermutlich auch schlecht. Vielleicht über ein Attribut konfigurierbar machen. Vielleicht auch shutdown um eine "force" Option ergänzen, die wie bisher sofort runterfährt, wenn es sein muss.
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19985
Antw:fhem shutdown mit verzögerung
« Antwort #2 am: 13 Januar 2019, 20:49:05 »
Eine Moeglichkeit ist, dass ShutdownFn oder UndefFn solange wartet, bis alle abhaengigen Resourcen freigegeben sind.
Das ist zwar weder blockierungsfrei, noch parallelisiert, das ist aber in diesem Fall auch nicht tragisch.

Die Alternative:
- ShutdownFn wird mit einem zusaetzlichen Hash aufgerufen, wo es melden kann, dass er nicht fertig ist.
- alle unfertigen Instanzen werden einmal die Sekunde aufgerufen, bis maximal X (global attribute).
- das uebliche select( wg. ReadFn) und InternalTimer laeuft in dieser Zeit _nicht_ weiter.

Bin fuer beide Varianten oder fuer weitere Vorschlaege offen.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15519
  • s/fhem\.cfg/configDB/g
Antw:fhem shutdown mit verzögerung
« Antwort #3 am: 13 Januar 2019, 21:01:58 »
ich mag rereadcfg sowieso nicht...

rereadcfg ist grundsätzlich an immer mehr Stellen ein Problem. Vielleicht sollten wir mal eine separate Diskussion über die Abschaffung dieser (höchstwahrscheinlich) entbehrlichen Altlast führen.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18657
Antw:fhem shutdown mit verzögerung
« Antwort #4 am: 13 Januar 2019, 21:14:20 »
@rudi: ja. im shutdown fall alles auf synchron umschalten wäre in meinem fall möglich. ich weiß nicht ob das in jedem anwendungsfall geht.

und man muss aufpassen nicht aus versehen blockieren zu lesen.

nachteil: doppelter code. ein mal readFn complett asynchron und dann das gleiche nochmal synchron nur für shutdown.  und das in jedem modul das diese möglichkeit braucht.

eine generelle möglichkeit shutdown zu verzögern wäre besser. nur ein mal code an zentraler stelle.

alternativ vorschlag da ich die ReadFn und auch InternalTimer brauche um asynchron zu beenden:

- ein device das noch zeit brauch liefert etwas anderes als undef aus ShutdownFn. meldung kommt ins log.

- wenn das passiert werden die hashes aller devices zentral in ein liste gepackt. und der shutdown nicht direkt ausgeführt. 

- das device hat jetzt alle fhem funktionen zur verfügung um im hintergrund alles sauber zu beenden.

- wenn das modul fertig ist nimmt es sich selber aus der liste.

- fhem prüft während dessen diese liste alle x sekunden. sobald die liste leer ist oder spätestens nach y sekunden wird alles hart beendet wie bisher.



wegen rereadcfg: ja. abschneiden und wegschmeißen. es gibt meiner meinung nach keinen vorteil gegenüber shutdown restart. dafür viele nachteile. und im normalfall kann man sowieso alles am live system machen.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19985
Antw:fhem shutdown mit verzögerung
« Antwort #5 am: 13 Januar 2019, 21:39:27 »
Zitat
alternativ vorschlag da ich die ReadFn und auch InternalTimer brauche um asynchron zu beenden:
- ein device das noch zeit brauch liefert etwas anderes als undef aus ShutdownFn. meldung kommt ins log.
Wenn select und InternalTimer weiterlaufen, dann wird das eine Menge von Perl-Warnungen oder gar Crashes von Modulen verursachen, die ShutdownFn/UndefFn nicht sauber implementiert haben, ich bin ja selbst bei meinen Modulen nicht sicher. Ich sage nicht, dass ein Aufraeumen sinnlos ist, auf der anderen Seite suche ich jetzt nicht gerade nach viel langweilige Arbeit.

Neuer Vorschlag: Es gibt eine DelayedShutdownFn Funktion, die von CommandShutdown zunaechst aufgerufen wird. Das, was kein undef zurueckliefert, wird in eine globale Liste eingetragen (wie von Andre vorgeschlagen), und diese Liste wird einmal die Sekunde bis max X Sekunden geprueft. Wenn Liste leer oder X Sekunden erreicht, geht mit bisherigen Shutdown weiter.


Zitat
wegen rereadcfg: ja. abschneiden und wegschmeißen.
Nicht dass ich rereadcfg mag oder gar verwende, aber danach gibt es hier einen Shitstorm von der fhem.cfg Editierfraktion. Bin nicht sicher, ob ich das jetzt haben will.
Vorschlag: rereadcfg auf deprecated setzen, und bei Problemen damit auf die Doku verweisen ud mit dem Schulter zucken.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15519
  • s/fhem\.cfg/configDB/g
Antw:fhem shutdown mit verzögerung
« Antwort #6 am: 13 Januar 2019, 21:48:16 »
Nicht dass ich rereadcfg mag oder gar verwende, aber danach gibt es hier einen Shitstorm von der fhem.cfg Editierfraktion. Bin nicht sicher, ob ich das jetzt haben will.

Die Lösung hat Andre doch schon geschrieben:

wegen rereadcfg: ja. abschneiden und wegschmeißen. es gibt meiner meinung nach keinen vorteil gegenüber shutdown restart.

Vorschlag: rereadcfg auf deprecated setzen, und bei Problemen damit auf die Doku verweisen ud mit dem Schulter zucken.

Das wäre (mir) als Dauerlösung zu halbherzig.

Anderer Vorschlag:

  • ab sofort auf deprecated setzen
  • bei der Ausführung des Befehls eine entsprechende Meldung ins Log schreiben
  • zum nächsten Major Release ausbauen und FHEM damit wieder um eine Problemstelle reduzieren
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18657
fhem shutdown mit verzögerung
« Antwort #7 am: 13 Januar 2019, 21:58:28 »
einverstanden mit DelayedShutdownFn

das verhindert auch das die bisherigen ShutdownFn aus versehen etwas zurück geben.

fehlt nur noch der name für die routine um sich aus der liste zu nehmen.

magst du einen patch vorschlag machen? oder soll ich?



auch einverstanden mit rereadcfg auf deprecated zu setzen. gleich mit einer entsprechenden ausgabe an den anwender wenn es verwendet wird.

ich frage mich gerade was passiert wenn man es einfach intern auf shutdown restart umbiegt. ich vermute fast das sie anwender noch nicht mal etwas bemerken.

fhemweb verbindet sich in jedem fall neu, telnet ist in jedem fall weg.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19985
Antw:fhem shutdown mit verzögerung
« Antwort #8 am: 13 Januar 2019, 22:03:41 »
Zitat
magst du einen patch vorschlag machen? oder soll ich?
Mache ich morgen, dann kann ich es direkt einchecken.

Zitat
ich frage mich gerade was passiert wenn man es einfach intern auf shutdown restart umbiegt. ich vermute fast das sie anwender noch nicht mal etwas bemerken.
Meine Vermutung: sie kriegen eine kaputte Seite in FHEMWEB, weil CSRF neu ist.
Ich schaut das morgen auch an.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15519
  • s/fhem\.cfg/configDB/g
Antw:fhem shutdown mit verzögerung
« Antwort #9 am: 14 Januar 2019, 08:55:22 »
ich frage mich gerade was passiert wenn man es einfach intern auf shutdown restart umbiegt.

Mein Bauchgefühl sagt mir, das könnte neue Probleme schaffen, auch wenn ich das im Moment nicht näher begründen kann.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 22.03.2019 - 18:30 Uhr im Baseler Hof

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19985
Antw:fhem shutdown mit verzögerung
« Antwort #10 am: 14 Januar 2019, 11:15:43 »
Folgendes ist ab sofort Implementiert:
- falls ein Modul eine DelayedShutdownFn Funktion implementiert, dann wird diese beim shutdown als erstes fuer alle Intanzen dieses Moduls aufgerufen.
- falls diese Funktion kein 0/undef zurueckliefert, dann wird der shutdown verzoegert, per Voreinstellung max 10 Sekunden, per "attr global maxShutdownDelay" aenderbar.
- ein Modul kann sich mit CancelDelayedShutdown("InstanzName") signalisieren, dass sie fertig ist, dann wird das normale shutdown frueher eingeleitet.
- falls die Verzoegerung notwendig ist, dann gibt es ein "global DELAYEDSHUTDOWN" Event, und eine entsprechende Meldung im Log.

Zu deprecated rereadcfg: ein einfaches Umbau zu "shutdown restart" fuehrt beim Speichern der fhem.cfg in FHEMWEB zu eine Fehlerseite.
Vermutlich ist das mit etwas mehr Aufwand zivilisierter zu loesen, das will ich aber nicht jetzt angehen.

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18657
Antw:fhem shutdown mit verzögerung
« Antwort #11 am: 14 Januar 2019, 16:31:36 »
funktioniert wunderbar.

danke!
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2631
    • HMCCU
Antw:fhem shutdown mit verzögerung
« Antwort #12 am: 15 Januar 2019, 09:07:56 »
2 Fragen dazu:

- Wird ShutodwnFn immer aufgerufen, also auch wenn DelayedShutdownFn definiert ist? Nur eben dann erst nach maxShutdownDelay Sekunden?
- Der per CancelDelayedShutdown signalisierte beschleunigte Shutdown wird erst eingeleitet, wenn alle Instanzen dies gemeldet haben?


2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18657
Antw:fhem shutdown mit verzögerung
« Antwort #13 am: 15 Januar 2019, 09:25:35 »
- ja

- ja
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19985
Antw:fhem shutdown mit verzögerung
« Antwort #14 am: 15 Januar 2019, 10:19:28 »
Wobei "beschleunigte Shutdown" mir nichts sagt.
Anders formuliert: falls einer der DelayedShutdownFns was meldet, dann wird shutdown erst in (max) 10 Sekunden "wirklich" aufgerufen.

Faellt mir gerade ein: falls ein Benutzer shutdown direkt nach einem gemeldeten delay nochmal aufruft, dann werden die DelayedShutdownFns nochmal aufgerufen.
Bin nicht sicher, ob das "egal" ist, oder ich das abfangen soll.

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18657
Antw:fhem shutdown mit verzögerung
« Antwort #15 am: 15 Januar 2019, 10:23:11 »
bei meiner implementierung ist es egal, aber ich denke ein hinweis das der shutdown schon läuft und nichts tun wäre besser.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19985
Antw:fhem shutdown mit verzögerung
« Antwort #16 am: 15 Januar 2019, 19:58:51 »
Eine Meldung habe ich nicht eingebaut (habe von Nebenwirkungen Angst), aber es wird verhindert, dass DelayedShutdownFn erneut aufgerufen wird.