fhem shutdown mit verzögerung

justme1968 · 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.

zap · 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.

rudolfkoenig · 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.

betateilchen · 13 Januar 2019, 21:01:58

Zitat von: justme1968 am 13 Januar 2019, 19:40:35
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.

justme1968 · 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.

rudolfkoenig · 13 Januar 2019, 21:39:27

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

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

betateilchen · 13 Januar 2019, 21:48:16

Zitat von: rudolfkoenig am 13 Januar 2019, 21:39:27
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:

Zitat von: justme1968 am 13 Januar 2019, 21:14:20
wegen rereadcfg: ja. abschneiden und wegschmeißen. es gibt meiner meinung nach keinen vorteil gegenüber shutdown restart.

Zitat von: rudolfkoenig am 13 Januar 2019, 21:39:27
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

justme1968 · 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.

rudolfkoenig · 13 Januar 2019, 22:03:41

Zitatmagst du einen patch vorschlag machen? oder soll ich?

Mache ich morgen, dann kann ich es direkt einchecken.

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

betateilchen · 14 Januar 2019, 08:55:22

Zitat von: justme1968 am 13 Januar 2019, 21:58:28
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.

rudolfkoenig · 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.

justme1968 · 14 Januar 2019, 16:31:36

funktioniert wunderbar.

danke!

zap · 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?

justme1968 · 15 Januar 2019, 09:25:35

- ja

- ja

rudolfkoenig · 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.