Ausfallsicherung
-
Teste mal
curl -s http://192.168.1.42/cm?cmnd=Power%20offcurl -s http://192.168.1.42/cm?cmnd=Power%20offcurl muss installiert sein
geht bei mir auf jede Fall mit der von mir verwendetet Software
-
oder so
var ip = '55'; //letzte Zahl der IP require("request")((['http://192.168.1.',('' + ip),'/cm?cmnd=cmnd=Power%20off'].join(''))).on("error", function (e) -
Übrigens wenn du deinen Rechner kontrolliert rebooten lassen willst, geht das auch:
createState('0_userdata.0.Reboot.t2c_System.LinuxRestart_command', ''); on({id: '0_userdata.0.Reboot.t2c_System.LinuxRestart_command', change: 'any'}, function (obj) { if (obj.newState.val === true || obj.newState.val === 'true'){ log('Command stop'); setState('0_userdata.0.Reboot.t2c_System.LinuxRestart_command', 'false'); exec ('sudo reboot'); } });In den angelegten DP true zum Zeitpunkt deiner Wahl schreiben... und exec im JS-Adapter zulassen.
Dann startet dein ioBroker durch.
EDIT:
Ich denke an so etwas hat @Homoran bestimmt gedacht, als er die Steckdose als Power on/off sah
-
@armilar aber wenn der iob hängt, geht ja nichts mehr.
-
@homoran
ich nehme immer an, dass mindestens ein Adapter seine Arbeit noch macht. Daher auch die JS-Instanz für PROD und eine für z.B. Wartung. Wenn der iob hängt, dann kann er höchstens versuchen sich mit VPN auf den pi zuzugreifen und ein sudo reboot aus der Console abzusetzen. Na und wenn das auch nicht mehr geht - Dann muss die Steckdose halt ran. -
Ja, wie schon gesagt, ich bin da auch nicht so zimperlich. Sollte das System tatsächlich doch Schaden nehmen, setze ich es eben neu auf, Backups habe ich ja. Und ca. alle 4 Wochen spiegele ich die SD Karte auf eine andere, sodass ich schnell wieder am Start wäre mit relativ wenig Aufwand.
Ich habe jetzt mal den Ansatz von @emil70 versucht mit dem Shellscript und dem curl Befehl (der auf der Konsole ohne Probleme funktioniert).
Allerdings komme ich da nicht recht weiter.#!/bin/bash #CONFIGURATION #IP of host GERAET=RasPi1 WATCH_IP="192.168.1.109" #path to logfile LOGFILE="/media/fritz.nas/SAMSUNG/RasPI/raspi1.log" #duration between pings PAUSE1=120 PAUSE2=10 #how many failed pings before log TESTS=2 #SCRIPT #initialize MISSED=0 # touch $LOGFILE #-lt = lesser than = kleiner als #-eq = equal = Gleichheit #-ne = not equal = Ungleichheit #-le = lesser or equal = kleiner oder gleich #-ge = greater or equal = größer oder gleich #-gt = greater than = größer als while true; do if ! ping -c 1 -w 1 $WATCH_IP > /dev/null; then echo $MISSED ((MISSED++)) else if [ $MISSED -ge $TESTS ]; then echo date "-" $GERAET "ist wieder online." >> $LOGFILE; fi MISSED=0 fi; if [ $MISSED -eq $TESTS ]; then echo date "-" $GERAET "wurde neu gestartet." >> $LOGFILE; curl -s http://192.168.1.42/cm?cmnd=Power%20off sleep $PAUSE2; curl -s http://192.168.1.42/cm?cmnd=Power%20on fi sleep $PAUSE1; doneDas Script bleibt aber mit der Meldung
./restart_raspi1.sh: 33: ./restart_raspi1.sh: MISSED++: not foundhängen, stört sich also an der Addition der Fehlversuche.
Bei shellCheck wird das Script als völlig korrekt angezeigt.
Was mache ich denn falsch? Oder würde das so überhaupt funktionieren?
Der Logfile wird erstellt, die Datei ist vorhanden (habe den touch Aufruf daher wieder auskommentiert).
Vielleicht könnt ihr nochmal drüber gucken ... -
@smartin
okay - dann bin ich raus...
-
Da ich hier noch nichts dazu gelesen habe noch eine Info:
Der Raspi4 hat wenn mein Wissensstand richtig ist einen HArdware Watchdog. Sollte sich der Pi4 aufhängen, d.h. der Watchdog nicht rechtzeitig getriggert werden, dann gibts einen HW Reset.
Welche Auswirkungen das auf Linux, insbesondere auf das Filesystem hat kann ich nict sagen. Da sollte man unbedingt noch genauer nachforschen.
-
Die Idee mit dem Watchdog direkt in der HW finde cool, würde auch installieren!
-
@mcm57 sagte in Ausfallsicherung:
Welche Auswirkungen das auf Linux, insbesondere auf das Filesystem hat kann ich nict sagen. Da sollte man unbedingt noch genauer nachforschen.
Ich hab das hier laufen, allerdings triggert hier die Load 1 Min.
Der Wachhund hat aber außerhalb von Tests nie angeschlagen.Die Anleitungen sind übrigens veraltet, mittlerweile ist das kein nachladbares Kernelmodul mehr sondern direkt in den Kernel gebacken worden.
-
@smartin sagte in Ausfallsicherung:
Gibt mal über Konsole das ein und poste den Log. Der wird da angelegt wo das script liegt
sh -x ./restart_raspi1.sh > debug.txt 2>&1Edit:
Der Logfile wird erstellt, die Datei ist vorhanden (habe den touch Aufruf daher wieder auskommentiert).
Dann solltest du auch
#echo date "-" $GERAET "ist wieder online." >> $LOGFILE; #echo date "-" $GERAET "wurde neu gestartet." >> $LOGFILE; -
debug.txt
+ GERAET=RasPi1 + WATCH_IP=192.168.1.109 + LOGFILE=/media/fritz.nas/SAMSUNG/RasPI/raspi1.log + PAUSE1=120 + PAUSE2=10 + TESTS=2 + MISSED=0 + true + ping -c 1 -w 1 192.168.1.109 + echo 0 0 + MISSED++ ./restart_raspi1.sh: 32: ./restart_raspi1.sh: MISSED++: not found + [ 0 -eq 2 ] + true + ping -c 1 -w 1 192.168.1.109 + echo 0 0 + MISSED++ ./restart_raspi1.sh: 32: ./restart_raspi1.sh: MISSED++: not found + [ 0 -eq 2 ] + true + ping -c 1 -w 1 192.168.1.109 + echo 0 0Deinen 2. Absatz verstehe ich nicht so ganz. Muss der touch Aufruf immer aktiv bleiben um das Log zu schreiben? Ich dachte das Logfile wird damit nur erstellt und die Logzeilen werden dann immer dort angehängt wenn er vorhanden ist. Deswegen hatte ich den Aufruf nach dem erstellen des Logfiles deaktiviert.
-
wegen dem 2.Absatz, hatte ich das falsch verstanden
touch $LOGFILEwird nicht benötigt, da mit
>> $LOGFILEer angelegt wird
Zu deinem Fehler. Ist die anzupingene IP die Richtige?
Da bei dir einecho 0kommt
Die Meldung
MISSED++: not foundist Richtig, wird sobald ein
+ MISSED=0und nicht ein
echo 0nicht mehr erscheinen
So der Log bei mir au smit deinen daten, da ich die IP nicht habe
+ GERAET=RasPi1 + WATCH_IP=192.168.1.109 + LOGFILE=/var/log/Sonoff/test.log + PAUSE1=120 + PAUSE2=10 + TESTS=2 + MISSED=0 + true + ping -c 1 -w 1 192.168.1.109 + echo 0 0 + MISSED++ ./test.sh: 25: ./test.sh: MISSED++: not found + [ 0 -eq 2 ] + sleep 120 + true + ping -c 1 -w 1 192.168.1.109 + echo 0 0 + MISSED++ ./test.sh: 25: ./test.sh: MISSED++: not found + [ 0 -eq 2 ] + sleep 120 + true + ping -c 1 -w 1 192.168.1.109 + echo 0So mit einer IP von mir
+ GERAET=Gartentorbeleuchtung1 + WATCH_IP=12.16.8.57 + LOGFILE=/var/log/Sonoff/Gartentorbeleuchtung1.log + PAUSE=60 + TESTS=10 + MISSED=0 + true + ping -c 1 -w 1 12.16.8.57 + echo 0 0 + MISSED++ ./Gartentorbeleuchtung1.sh: 31: ./Gartentorbeleuchtung1.sh: MISSED++: not found + [ 0 -eq 10 ] + sleep 60 + true + ping -c 1 -w 1 12.16.8.57 + [ 0 -ge 10 ] + MISSED=0 + [ 0 -eq 10 ] + sleep 60 + true + ping -c 1 -w 1 12.16.8.57 + [ 0 -ge 10 ] + MISSED=0 + [ 0 -eq 10 ] + sleep 60 + true + ping -c 1 -w 1 12.16.8.57 + [ 0 -ge 10 ] + MISSED=0 + [ 0 -eq 10 ] + sleep 60 + true + ping -c 1 -w 1 12.16.8.57 + [ 0 -ge 10 ] + MISSED=0Edit: Du muss, wenn Alles geht in die
/etc/crontabdas reinschreiben, so wie das script ausgführt und die Prüfschleife wiederholt sich immer wieder
@reboot root /dein Pfad zum script/restart_raspi1.shDanch ein reboot durchführen
-
Wie wäre es mit einem Skript auf dem Raspi selbst? Also z.B. minütlich prüfen, ob ein Ping, z.B. zum Router fehl schlägt und dann einen Reboot hinlegen.
Hängt der Raspi selbst, kann man nach einer längeren Zeit, wie z.B. 5 Minuten, die Steckdose immer noch kurz abschalten.
Zur Fehlersuche würde ich mir den freien RAM mitloggen.
-
@smartin
https://www.ute.de/produkte/pdus/zwischenstecker-fuer-steckdosen/ip-single-pro.html#:~:text=Die IP-Steckdosenleiste verfügt zudem,automatisch die Stromversorgung wieder her.wenn der PI wirklich nicht anpingbar ist.
-
Meine Ausfallsicherung funktioniert so, dass ich Raspi an einem Fritzbox DECT Schalter hängen habe. Falls ich im Urlaub nicht auf meine Smarthome-Geräte zugreifen kann, starte ich über die FritzApp den DECT Zwischenstecker neu. Leider funktioniert die App seit der Umstellung auf Glasfaser nicht mehr.
Aber die Idee mit dem eingebauten Watchdog finde ich richtig gut, warum nutzt es hier keiner?
