Welche Nachteile hat "rereadcfg" im Vergleich zu "shutdown restart"?
In Developmentthread https://forum.fhem.de/index.php/topic,95819.0.html wurde nebenbei diskutiert, dass rereadcfg ungeliebt ist und (in welcher Form auch immer) weg soll. In diversen Wiki-Artikeln wird immer wieder "rereadcfg" als Alternative zu "shutdown restart" angeführt ohne auf Unterschiede/Probleme einzugehen. Eigentlich wollte ich rereadcfg aus den Artikel löschen, würde aber gerne vorher verstehen, warum es "schlecht(er)" ist. Kann das bitte jemand für Anwender erläutern?
Im genannten Developerthread wurde über die Absicht "rereadcfg=deprecated" geschrieben. Entsprechende Hinweise enthält die commandref bis heute nicht. Ist das kein Thema mehr?
Und nein, ich habe rereadcfg bisher nicht genutzt, da ich den Vorteil im Vergleich zu "shutdown restart" auch nie verstanden/gefunden habe.
Danke und Gruß, Christian
Nachteil 1: der Funktionsname suggeriert (oder sehe nur ich das so?), dass man bei Verwendung von #include eine einzelne .cfg (Teil-)Datei neu einlesen kann (nachdem man sie unerwünschterweise "externen" editiert hat). Meines Wissens ist das aber nicht so.
Rereadcfg:
- schreibt das statefile
- ruft fuer alle Definitionen UndefFn auf
- entfernt so ziemlich alle globale Variablen, wie %defs, @intAtA, %selectList, etc
- liest fhem.cfg oder configDb ein, gefolgt vom statefile
- triggert global REREADCFG
Bedeutet:
- internalTimer gehen verloren, z.Bsp. das on-for-timer von SetExtensions, watchdog Status, sequence, etc.
- alle Verbindungen zu externen Geraeten (USB, Netzwerk, etc) werden neu initialisiert: Daten, die waehrend zumachen und neu oeffnen geliefert werden, gehen verloren.
- genauso stehen waehrend dieser Zeit FHEM-Dienste (FHEMWEB/MQTT2_SERVER) nicht zur Verfuegung.
- etliche Module holen bei der Definition den Status vom Geraet ab, und das teilweise blockierend: ich habe Konfigurationen gesehen, die beim Start 30+ Sekunden exklusiv mit Initialisieren beschaeftigt waren.
Falls man im FHEMWEB fhem.cfg editiert, wird beim Speichern rereadcfg ausgefuehrt.
Beim shutdown restart wird zusaetzlich:
- 2 Sekunden geschlafen
- Prozess neu gestartet (dh. Speicher freigegeben)
- damit auch alle Module (FHEM+Perl) neu eingelesen.
Zu Christians Frage (habe gerade den Link wieder gelesen): da bei rereadcfg die aktuelle Verbindung nicht zugemacht wird, gibt es keine Fehlermeldung, wenn man es aus FHEMWEB ausloest. Das kann man vermutlich mit enstprechenden Aufwand umgehen.
Ist das zu weit interpretiert: rereadcfg "sollte" problemlos funktionieren, aber nur "shutdown restart" garantiert ein konsistentes FHEM. Wenn rereadcfg zu seltsamen Problemen führt, dann mache "shutdown restart" und teste bevor die Probleme berichtet werden.
Die negative Developer-Einstellung zu rereadcfg, die sich auch in https://forum.fhem.de/index.php/topic,96164.0.html findet, erschließt sich mir noch nicht wirklich.
Im Forum finde ich Schwierigkeiten mit rereadcfg im Wesentlichen nur im Zusammenhang mit blocking. Ob das aber an rereadcfg liegt oder an nicht optimalen Modulen kann ich nicht bewerten.
deprecated ist demnach kein Thema.
ZitatDie negative Developer-Einstellung zu rereadcfg, die sich auch in https://forum.fhem.de/index.php/topic,96164.0.html (https://forum.fhem.de/index.php/topic,96164.0.html) findet, erschließt sich mir noch nicht wirklich.
Meine Vermutung: rereadcfg suggeriert nicht, dass das System praktisch neu gestartet wird.
ZitatIm Forum finde ich Schwierigkeiten mit rereadcfg im Wesentlichen nur im Zusammenhang mit blocking.
rereadcfg kuemmert sich nicht explizit um Blocking (shutdown restart auch nicht), Module, die Blocking verwenden, muessen das in UndefFn selbst tun.