X_DelayedShutdown vs. X_Undef

[jw2013]

Ist es angedacht, CommandRereadCfg so anzupassen, dass eine Definition zukünftig auch die Ausführung von RereadCfg (SIGHUP) verzögern kann, analog zu shutdown?

Also sowas wie "X_DelayedUndef" ...

Es fühlt sich irgendwie falsch an, dass eine Definition nach einem SIGTERM Signal noch mehr Optionen hat, Daten zu retten oder aufzuräumen, als nach einem SIGHUP.

(nur meine 2 EUR-Cent)
 - jens

[betateilchen]

Die m.E. "bessere" Lösung wäre, dieses unsägliche rereadcfg endlich irgendwann abzuschaffen.

[jw2013]

Oder so 

Etwas Anderes wäre es m.E., wenn rereadcfg die bestehenden Definitionen beibehalten würde.

Aktuell werden diese gelöscht und neu erzeugt, weswegen das System in der Zwischenzeit u.a. die Server-Sockets schliesst und neue Verbindungen ablehnt, was dem üblichen Verhalten von SIGHUP widerspricht.

Wenn das Verhalten so wäre, dass rereadcfg fortbestehende Definitionen erhalten würde, und nur aus der Konfiguration entfernte löscht, könnte man für letztere den bestehenden DelayedShutdown Mechanismus nutzen (statt undef).

[betateilchen]

Die Diskussion über rereadcfg gab es in der Vergangenheit ja schon öfters.

Der Hauptkritikpunkt an diesem Befehl ist die Tatsache, dass man nach der Ausführung nicht zwingend einen klar definierten Zustand des gesamten Systems erwarten kann, wie das z.B. nach "shutdown restart" der Fall ist. Das von Dir beschriebene Thema ist nur ein Aspekt in diesem gesamten Kontext.

Aber bisher war Rudi noch nicht davon zu überzeugen, dieses Manko durch Entfernen zu beseitigen. Vielleicht kommt es ja zu "FHEM 7" 

[rudolfkoenig]

Es fühlt sich irgendwie falsch an, dass eine Definition nach einem SIGTERM Signal noch mehr Optionen hat, Daten zu retten oder aufzuräumen, als nach einem SIGHUP.

Existiert ausser falschen Gefuehlen ein konkretes Problem?

Die m.E. "bessere" Lösung wäre, dieses unsägliche rereadcfg endlich irgendwann abzuschaffen.

FHEMWEB braucht rereadcfg z.Zt. fuer das Editieren der fhem.cfg, das liesse sich aber auf shutdown restart umbauen.
Und wenn man FHEM per config/init-scripts/fhem.service startet (type=forking) dann duerfte es auch keine Probleme verursachen.

Will sagen: ich habe kein Problem mit dem Entfernen von rereadcfg.

[jw2013]

Existiert ausser falschen Gefuehlen ein konkretes Problem?

Ja (aber andersweitig lösbar/gelöst): Bsp, externe Software verwendet FHEMWEB Server Socket als API Endpunkt. Die Verbindung wird bei jedem rereadcfg/SIGHUP geschlossen, und kann nicht sofort reconnecten.

Mein Punkt war, das könnte man etwas eleganter lösen. Wenn sich den der Definition der FHEMWEB Instanz nichts ändert, sollte auch der Server-Socket unverändert, und Client-Verbindungen bestehen bleiben.

Will sagen: ich habe kein Problem mit dem Entfernen von rereadcfg.

Man müsste das Kommando noch nicht einmal entfernen, sondern das könnte man m.E. sauber umbauen.

Wenn ich gerade "den Chef an der Leitung habe" Was war damals die Absicht hinter der Auftrennung in X_Undef und X_Shutdown?

[betateilchen]

Will sagen: ich habe kein Problem mit dem Entfernen von rereadcfg.

Heureka!

Man müsste das Kommando noch nicht einmal entfernen, sondern das könnte man m.E. sauber umbauen.

Das würde voraussetzen, dass alle Module korrekt damit umgehen, und das ist eben nicht der Fall, was immer wieder zu einigen Ungereimtheiten führt, die sich dann aber durch ein "shutdown restart" beseitigen lassen.

Was war damals die Absicht hinter der Auftrennung in X_Undef und X_Shutdown?

Reine Vermutung:

X_Undef ist sehr viel älter, da es (auch heute noch) für das Löschen von devices gedacht war und damit nicht zwingend etwas mit dem Stoppen oder Neustarten des Servers zu tun hat.