Ausfallsicherung

[Armilar]

@smartin
na 3x in 3 Jahren. Ziehen wir mal den admin.0 ab.

Dann gibt es alle 1,5 Jahre mal gemecker... Da würde ich auch nicht viel investieren

Eine zweite JS-Instanz kann schon Sinn machen. Nutze die auch zum Testen, da beim kompilieren globaler TS-Skripte ein JS-Neustart ja vorprogrammiert ist. Auf einer weiteren Instanz läuft dann ein Watchdog.

function createNotification(notificationText) {
    sendTo("telegram", "send", {text: notificationText});
}
  
on({id: /^system\.adapter\..+\.alive$/, change: 'ne', val: false}, function (dp) {
    var id = dp.id.split('.');
    id = 'system.adapter.' + id[2] + '.' + id[3];
    var instance = getObject(id);
    var ignoreList= ["dwd.0 alive", 
                     "ical.0 alive", 
                     "ical.1 alive",
                     "knmi-weather.0 alive",
                     "weatherunderground.0 alive",
                     "pegelalarm.0 alive", 
                     "openweathermap.0 alive",
                     "uv-protect.0 alive",
                     "luftdaten.0 alive",
                     "odl.0 alive",
                     "daswetter.0 alive",
                     "followthesun.0 alive",
                     "feiertage.0 alive",
                     "coronavirus-statistics.0 alive"];

    if (!ignoreList.includes(dp.common.name) && instance.common.enabled) {
        createNotification(dp.common.name);
        console.log(dp.common.name);
    }
});

Erzählt immer fleißig was an Instanzen Probleme hat.

[emil70]

@smartin

Ich lass meine Sonoff mit der Software überwachen, ob sie online sind. Wenn nicht werden sie neu gestartet.

Spoiler

#!/bin/bash

check and log if a host is reachable by ping

#CONFIGURATION

#IP of host
GERAET=Buerobeleuchtung
WATCH_IP="192.168.178.40"
#path to logfile
LOGFILE="/var/log/Sonoff/Buerobeleuchtung.log"
#duration between pings
PAUSE=60
#how many failed pings before log
TESTS=10

#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;
echo "reboot" | socat - udp-sendto:192.168.178.40:6676
fi
sleep $PAUSE;
done

Müsste man anpassen

Das script arbeitet als Schleife

socat muss installiert sein

[Armilar]

@emil70

Auch interessant. Ein Watchdog für Tasmotas außerhalb ioBroker.

[Smartin]

@emil70

Das ist klasse!
Genauso wie übrigens das Überwachungs-Script von @armilar

Ich bin allerdings wie gesagt nicht so wirklich ein Linux/Script-Held ...
Ich vermute in dieser Zeile würde ich den Aus/An Befehl unterbringen müssen

echo "reboot" | socat - udp-sendto:192.168.178.40:6676

Richtig?
Wie müsste das aussehen, wenn der Befehl

http://192.168.1.42/cm?cmnd=Power%20off

bzw.

http://192.168.1.42/cm?cmnd=Power%20on

lautet und dazwischen noch eine Pause von 10 Sekunden eingehalten werden soll?

[emil70]

@smartin

ja das ist der Part

Du nutzt Tasmota, so wie ich die Befehle sehe. Das nutze ich leider nicht und kann da nicht sagen, wie da der Befehl über Konsole lautet. http geht so auf jeden Fall nicht

Vielleicht geht bei Tasmota ssh

ssh IP vom Sonoff -p 22 -l "reboot"

[Armilar]

@smartin

https://tasmota.github.io/docs/Commands/#with-web-requests

Ist schon korrekt so

[Homoran]

@emil70 sagte in Ausfallsicherung:

Pack den Pi doch an eine Schaltbare Steckdose und nutzt ein script auf einem anderen System,was den Pi anpingt. Ist dieser nicht erreichbar wird die Steckdoese aus und nach ein paar Sekunden wieder eingeschlaltet.

Das wären dann ja doch wieder zwei Geräte.

Außerdem müsste man jetzt genau wissen was unter Ausfall zu verstehen ist.
Auch ich

@armilar sagte in Ausfallsicherung:

dachte bei Ausfallsicherheit eigentlich an Redundanz und Hochverfügbarkeit.

und wenn es nur um

@smartin sagte in Ausfallsicherung:

einem Neustart

geht wäre

@emil70 sagte in Ausfallsicherung:

eine Schaltbare Steckdose

so ziemlich das Teil was man nicht als erste Wahl nehmen sollte.
Die Folgen von "reboot" durch Stecker raus sollten ja inzwischen hinlänglich bekannt sein.

EDIT:
Wo kommen denn jetzt auf einmal die ganzen Posts her?
Da war gerade nix!

also vergesst meinen Post, ist ja nix neues

[emil70]

@smartin

Teste mal

curl -s http://192.168.1.42/cm?cmnd=Power%20off

curl -s http://192.168.1.42/cm?cmnd=Power%20off

curl muss installiert sein

geht bei mir auf jede Fall mit der von mir verwendetet Software

[Armilar]

@smartin

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) 

[Armilar]

@Smartin

Ü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

[Homoran]

@armilar aber wenn der iob hängt, geht ja nichts mehr.

[Armilar]

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

[Smartin]

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;
done

Das Script bleibt aber mit der Meldung

./restart_raspi1.sh: 33: ./restart_raspi1.sh: MISSED++: not found

hä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 ...

[Armilar]

@smartin
okay - dann bin ich raus...

[mcm1957]

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.

https://www.gieseke-buch.de/raspberrypi/eingebauten-hardware-watchdog-zur-ueberwachung-nutzen#:~:text=Eine der Besonderheiten des Raspberry,Störung nicht mehr ordnungsgemäß läuft.

https://www.raspberry-buy.de/Tutorial_Raspberry_Pi_Watchdog_installieren_konfigurieren_aktivieren.html

[Santos]

Die Idee mit dem Watchdog direkt in der HW finde cool, würde auch installieren!

[Thomas Braun]

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

[emil70]

@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>&1

Edit:

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;

[Smartin]

@emil70

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
0

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

[emil70]

@smartin

wegen dem 2.Absatz, hatte ich das falsch verstanden

touch $LOGFILE

wird nicht benötigt, da mit

>> $LOGFILE

er angelegt wird

Zu deinem Fehler. Ist die anzupingene IP die Richtige?
Da bei dir ein

echo 0

kommt

Die Meldung

MISSED++: not found

ist Richtig, wird sobald ein

+ MISSED=0

und nicht ein

echo 0

nicht 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 0

So 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=0

Edit: Du muss, wenn Alles geht in die

/etc/crontab

das reinschreiben, so wie das script ausgführt und die Prüfschleife wiederholt sich immer wieder

@reboot root /dein Pfad zum script/restart_raspi1.sh

Danch ein reboot durchführen