Shutdown vor Server-Neustart

Begonnen von uwirt, 18 Januar 2022, 10:23:37

Vorheriges Thema - Nächstes Thema

uwirt

Ich habe bei meinen FHEM Server für in der Nacht einen Server-Neustart über crontab programmiert:

0 4 * * * sudo shutdown -r

Gibt es eine Möglichkeit vor dem Neustart FHEM korrekt herunterzufahren und danach gleich anschliessend den Server-Neustart zu machen?
FHEM / Ubuntu / fitlet2
HomeMatic: CCU3|HmIP-STHD|HmIP-PCBS|HmIP-PCBS2|HmIP-PCBS-BAT|HM-WDC7000|HM-WDS100-C6-O|HM-WDS40|HM-LC-Sw1-FM|HM-LC-RGBW-WM|HM-ES-PMSw1-Pl|HM-ES-TX-WM
NAS: DS218+|DS209j|DS216+II|DS412+
Devices: Panasonic Webcams|Withings|Gardena Smart

Beta-User

Nach meiner Kenntnis wird FHEM (wenn über init.d oder systemd gestartet) prinzipiell auch "save" heruntergefahren (also insbesondere die statefile gesichert!), wenn ein shutdown-Command kommt.

Problematisch ist das externe runterfahren nur, wenn FHEM zu langsam ist, um das abzuschließen. Ich würde daher darauf tippen, dass du zu viele (unnötige) Events hast, schlechte regexpe (NOTIFYDEV nicht gebildet) oder deine Hardware eben insgesamt zu langsam ist für die Zahl der FHEM-Geräte.

PS: welchen Sinn hat das, eine Linux-Maschine jeden Tag zu booten?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Damian

Du kannst es einfach testen:

Dummy anlegen und auf on setzen.

sudo shutdown -r

ausführen und nach dem Hochfahren schauen was mit dem Dummy ist.


Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Beta-User

Zitat von: Damian am 18 Januar 2022, 11:27:00
Du kannst es einfach testen:
Der TE hat verschwiegen, dass er die Frage stellt, weil es zu Verlusten bei Reading-Werten gekommen war. Daher auch meine Vermutung, dass FHEM zu lange braucht...

https://forum.fhem.de/index.php/topic,10580.msg1201232.html#msg1201232?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

#4
unit-file so konfigurieren, dass systemd Bescheid weiß "es dauert länger" bin nicht sicher wie man das zielgenau macht. RestartSec ?
Oder im crontab einfach zwei Befehle (Script) machen:
systemctl stop fhem
# eventuell noch ein Sicherheitssleep
shutdown -r

Ist das system crontab? Wozu dann sudo? Der wird doch als root ausgeführt?!

Oder im unit file den Restart=always rausnehmen und FHEM - 5 vor 4 - selbst mit einem at beenden  ;D
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Vielleicht nochmal einen Schritt zurück:
Zitat von: Beta-User am 18 Januar 2022, 10:37:48
Problematisch ist das externe runterfahren nur, wenn FHEM zu langsam ist, um das abzuschließen.
Bevor wir Symptombekämpfung machen, sollte man wirklich die Frage stellen, warum die "Standardzeit" nicht ausreicht, damit FHEM sich beendet! Das reicht doch typischerweise auch aus! (Die Dauer sollte afaik bei ca. 90 Sekunden liegen, bevor das "kill"-Kommando kommt...)

Kurz: Dieses FHEM ist verbogen! (Und der Versuch, das per täglichem Neustart zu "reparieren", ist es im Übrigen auch!)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

Zitat von: uwirt am 18 Januar 2022, 10:23:37
0 4 * * * sudo shutdown -r

Zitat von: Otto123 am 18 Januar 2022, 12:16:29
Ist das system crontab? Wozu dann sudo? Der wird doch als root ausgeführt?!

Wenn es die systemeigene crontab Tabelle wäre, würde ein Benutzername im Eintrag stehen...

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

uwirt



ZitatKurz: Dieses FHEM ist verbogen! (Und der Versuch, das per täglichem Neustart zu "reparieren", ist es im Übrigen auch!)

Dann stellt sich die Frage wie ich das verbogene FHEM am besten wieder gerade kriege. Mir wäre Ursachenbehebung auch lieber als Symptombekämpfung.
FHEM / Ubuntu / fitlet2
HomeMatic: CCU3|HmIP-STHD|HmIP-PCBS|HmIP-PCBS2|HmIP-PCBS-BAT|HM-WDC7000|HM-WDS100-C6-O|HM-WDS40|HM-LC-Sw1-FM|HM-LC-RGBW-WM|HM-ES-PMSw1-Pl|HM-ES-TX-WM
NAS: DS218+|DS209j|DS216+II|DS412+
Devices: Panasonic Webcams|Withings|Gardena Smart

Beta-User

Na ja, nur du kannst wissen, ob sich dein FHEM irgendwie "langsam" anfühlt und was da so an Events kommt, wenn du den Event-Monitor aufmachst.

Ansatzpunkte, um die Zahl der Events und die Verarbeitungsgeschwindigkeit ggf. zu optimieren wären z.B. in diesen Thread zu finden: https://forum.fhem.de/index.php/topic,117075.0.html
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wernieman

Und auch einfach mal auf Systemebene gucken, was denn FHEM so als Recourcen "frisst" (Speicher, CPU etc.)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html