von anderem Pi testen, ob der FHEM-Pi noch online ist

[Invers]

Hi, möchte, wie in der Überschrift geschrieben testen, ob mein Pi, auf dem FHEM läuft noch erreichbar ist.
Dafür dachte ich, einen Ping auf die FHEM-Pi zu machen und bei Nichterreichbarkeit den pingenden Pi neu zu booten.
Da dafür ja wahrscheinlich nur ein Cronjob o.Ä. infrage kommt, bitte ich euch mangels Ahnung um Hilfe.

Vielen Dank im Voraus.

[CoolTux]

Schon eine Idee wie Du den nicht zu erreichen Pi rebooten willst? Er wird ja dann wohl tot sein, remote Commander wird da wohl nicht gehen.

[MadMax-FHEM]

Warum den PI der pingt booten, wenn er den fhem PI nicht mehr erreicht!?

Und wenn der abdere PI (auf dem fhem läuft) nicht per ping erreichbar ist, wird es auch schwer (unmöglich) diesen remote zu booten...

Warum willst du das tun?
Probleme mit dem PI auf dem fhem läuft?
Lieber die lösen...

Ansonsten gibt es (gefühlt) tausend Threads wo Scripts etc. auf dem fhem-Server selbst prüfen, ob fhem noch tut und dann booten oder fhem neu starten...

Also noch mal überdenken was du tatsächlich aus welchem Grund tun willst...

Kurz da nur Handy...

Gruß, Joachim

[Invers]

Wenn der neu zu bootende Pi den anderen nicht mehr erreicht, soll einfach der Bootvorgang ausgelöst werden. Also bei dem pingenden Pi.
Ich gehe davon aus, dass der Pi, wenn er selber nicht mehr erreichbar ist, auch den anderen nicht erreichen kann. Irgendwie scheint sich da immer das Netz zu verabschieden. Deshalb wollte ich in einem solchen Fall einfach, dass der Pi sich selber bootet. Falls man anders abgreifen kann, ob das Netzwerk noch läuft, kann man natürlich auch anders vorgehen. Ich habe aber davon zu wenig Ahnung.

[MadMax-FHEM]

Wie ist denn der PI (auf dem fhem läuft) ins Netz eingebunden?
WLAN?
LAN?
DHCP?
Statische IP?

Bist du sicher dass nur das Netzwerk "gestört" ist oder läuft fhem nicht mehr?

Wie äußert sich das (für dich)?

Und wie bereits geschrieben: es gibt bereits einiges bzgl. fhem Überwachung etc.

EDIT: du brauchst dazu keinen weiteren PI. Richte doch ein Presence mit LAN ping auf deinen Router (oder sogar externen DNS) in fhem ein. Dann ein Notify auf absent und einen Reboot... Also alles lokal auf dem fhem PI. Was auf einem anderen PI/Rechner einrichten macht doch (wie mehrfach geschrieben) keinen Sinn...

EDIT2: und bezeichne mal die PIs etwas genauer, damit klar ist was du jetzt auf dem PI wo fhem läuft (und überwacht werden soll) passieren/eingerichtet werden soll und was (wozu auch immer) auf einem anderen PI/Rechner passieren/gemacht werden soll...

Gruß, Joachim

[CoolTux]

Ich dafür Mal ein Script geschrieben. Allerdings ohne rebooten sondern mit Netzwerk Neustart. Ich schaue nachher mal.

[Prof. Dr. Peter Henning]

Netzwerke "laufen" nicht. Das Problem liegt hier wohl eher bei den Netzwerkadaptern - z.B. legen sich manche WLAN-Adapter selbst nach einiger Zeit in den Schlafmodus.
So lange hier aber keine aussagekräftige Fehlerbeschreibung veröffentlicht ist, mit genauem Hinweis auf die verwendete Hardware, lässt sich kaum etwas Konkretes sagen.

Selbst dann würde ich niemals FHEM für die Überwachung verwenden - das bremst die Kiste viel zu sehr aus. Dafür hat es den eingebauten Hardware-Watchdog.

Ich habe aber davon zu wenig Ahnung.

Na, das sollte man dann schnellstens ändern.

LG

pah

[Invers]

Irgendwie gibt es hier ein Missverständnis.
Der Pi, auf dem FHERM läuft, funktioniert einwandfrei.
Auf dem entfernten Pi läuft Webradio. Dieser Pi fliegt hin und wieder aus dem Netz. Das ist aber nun nicht wirklich tragisch, dann spielt das Radio auf dem Klo halt nicht. Radio-Pi lässt sich dann auch nicht mehr pingen und FHEM sagt, no route to host. Daher meine Idee, den Radio-Pi bei Kontaktverlust neu zu booten, oder das Netzwerk neu zu starten. Das kann der FHEM-Pi natürlich nicht, da ja der andere Pi nicht erreichbar ist. Somit muss der Radio-Pi das selber machen.

@CoolTux
An dem Skript wäre ich sehr interessiert.

@MadMax-FHEM
Der Pi ist per WLAN eingebunden und manchmal, wenn die Fritzbox neu gestartet wird, hat das negative Auswirkungen.
Die Box macht halt offenbar Fehler. Gestern z.B. habe ich einen WLAN-Stick von AVM per surf and go eingebunden. Wie sich später herausstellte hatte die Fritzbox die IP, die ich bereits fest an den HMLAN vergeben hatte, ebenfalls dem neuen Stick zugeordnet.
Ich will nicht FHEM überwachen, sondern den entfernten Radio-Pi. FHEM läuft stabil.

Na, das sollte man dann schnellstens ändern.

Ja, das sollte man wohl. Aber die Lebenszeit ist nicht unendlich. Ich müsste erst einmal englisch lernen, dann Linux und wenn man dann 65 Jahre alt ist, fällt das auch nicht mehr ganz so leicht, wie mit 55. Das halte ich bei einer so kleinen Aufgabe für übertrieben.
Natürlich "laufen" Netzwerke nicht. Das tun Motoren auch nicht. Ich habe mich einfach nur volkstümlich ausgedrückt.
Den Sleepmodus des Adapters kann ich ausschliessen, da der Pi oft tagelang durch"läuft". Meine verwendete Hardware steht in der Signatur. FHEM soll auch den Radio-Pi nicht überwachen, das soll der Radio-Pi ja gerade selber machen. Der hat auch genug Zeit, da er ja keinerlei Schwerstarbeit zu verrichten hat.

[Prof. Dr. Peter Henning]

Eben darum sollte auf ihm der Watchdog aktiviert werden. Der problemlos für einen Neustart sorgt, wenn der Router nicht mehr erreichbar ist.

Anleitungen dafür gibt es wie Sand am Meer, ich habe - wenn ich mich Recht erinnere, auch in den SmartHome Hacks etwas dazu geschrieben. Einfach "watchdog raspberry pi" bei Google eingeben.

LG

pah

P.S.: Bitte nicht mit dem Alter kokettieren. Bei mir steht auch eine 6 am Anfang, und ich muss täglich Neues lernen.

[CoolTux]

Code Auswählen Erweitern


#!/bin/bash
# /usr/local/bin/check_NETalive.sh
##
PATH=/sbin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/usr/local/bin
HOST=`hostname`

        if [ $(cat /sys/class/net/wlan0/carrier) = 0 ] || [ $(cat /sys/class/net/vlan60/carrier) = 0 ]; then

                if [ $(cat /sys/class/net/wlan0/carrier) = 0 ]; then
                        ifup wlan0
                        echo "wlan0 Interface on $HOST is down, i'll see if i can wake him up!! Next check in 10 min" | mail -s "wlan0 on $HOST is DOWN!!!" test@test.de
                exit 0
                elif [ $(cat /sys/class/net/vlan60/carrier) = 0 ]; then
                        ifup vlan60
                        echo "Public Network vlan60 on $HOST is down, i'll see if i can wake him up!! Next check in 10 min" | mail -s "vlan60 on $HOST is DOWN!!!" test@test.de
                exit 0
                fi
        fi
exit 0


Musst Deine Adapter halt anpassen und statt aud 2 nur auf einen prüfen. Sollte ja gehen.
Das Script lässt du einfach per cron alle 10min laufen.

[blofield]

Ich nutze den auf dem Raspberry Pi den eingebauten Hardware Watchdog.
Eingerichtet nach: https://blog.doenselmann.com/raspberry-pi-fuer-dauereinsatz-optimieren/
FHEM lasse ich alle 5 Minuten eine Datei schreiben, die vom zyklisch watchdog geprüft wird. Geht das nicht mehr, wird der Raspbi automatisch neu gestartet.

Funktioniert seit Jahren ausserordentlich zuverlässig und man braucht auch kein zweites Gerät das prüft

blofield

[MadMax-FHEM]

Irgendwie gibt es hier ein Missverständnis.
Der Pi, auf dem FHERM läuft, funktioniert einwandfrei.
Auf dem entfernten Pi läuft Webradio. Dieser Pi fliegt hin und wieder aus dem Netz. Das ist aber nun nicht wirklich tragisch, dann spielt das Radio auf dem Klo halt nicht. Radio-Pi lässt sich dann auch nicht mehr pingen und FHEM sagt, no route to host. Daher meine Idee, den Radio-Pi bei Kontaktverlust neu zu booten, oder das Netzwerk neu zu starten. Das kann der FHEM-Pi natürlich nicht, da ja der andere Pi nicht erreichbar ist. Somit muss der Radio-Pi das selber machen.

Gut jetzt ist klar(er) was du willst

EDIT: dann passt aber der Betreff mal so gar nicht

@MadMax-FHEM
Der Pi ist per WLAN eingebunden und manchmal, wenn die Fritzbox neu gestartet wird, hat das negative Auswirkungen.
Die Box macht halt offenbar Fehler. Gestern z.B. habe ich einen WLAN-Stick von AVM per surf and go eingebunden. Wie sich später herausstellte hatte die Fritzbox die IP, die ich bereits fest an den HMLAN vergeben hatte, ebenfalls dem neuen Stick zugeordnet.
Ich will nicht FHEM überwachen, sondern den entfernten Radio-Pi. FHEM läuft stabil.

Was macht dich außer dem "er läuft ja ein paar Tage durch" so sicher, dass es nicht doch das WLAN-Sleep ist?
Lieber mal prüfen...

Ist alles die gleiche PI-HW?
In der Signatur steht ja nur einer

Und ich würde statische IPs eben auch nur im DHCP-Server (Fritzbox) einstellen und nicht "mal so und mal so" (also mal direkt beim Gerät und den Rest per DHCP), dann kann so ein Durcheinander nicht passieren...
...könnte auch ein Grund sein warum das dann ab und an mal hakt mit dem Net-Radio

Gruß, Joachim

[Dr. Boris Neubert]

Hallo CoolTux,

Code Auswählen Erweitern


        if [ $(cat /sys/class/net/wlan0/carrier) = 0 ] || [ $(cat /sys/class/net/vlan60/carrier) = 0 ]; then

                if [ $(cat /sys/class/net/wlan0/carrier) = 0 ]; then
                        ifup wlan0
                        echo "wlan0 Interface on $HOST is down, i'll see if i can wake him up!! Next check in 10 min" | mail -s "wlan0 on $HOST is DOWN!!!" test@test.de
                exit 0


das Besondere an Deiner Lösung ist die Prüfung auf /sys/class/net/wlan0/carrier! Das ist sehr schön, weil diese Lösung nicht davon abhängt, ob ein Host im Netz erreichbar ist. Ich möchte ja nicht, dass der Raspberry glaubt, keine Verbindung zu haben, nur weil der Host wegen Wartungsarbeiten nicht erreichbar ist. Diese Situation entsteht bei mir, weil ich mehrere WLAN-AccessPoints habe und damit Host down nicht gleich WLAN down bedeutet.

Für den, den es interessiert: die Doku zu /sys/class/net ist hier: https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net

Ich habe ansonsten ein ähnliches Skript laufen. Ich verwende die Sequenz

Code Auswählen Erweitern

/sbin/ifdown 'wlan0'
sleep 5
/sbin/ifup --force 'wlan0'

zum Neustarten der Verbindung.

Viele Grüße
Boris

[Invers]

Eben darum sollte auf ihm der Watchdog aktiviert werden. Der problemlos für einen Neustart sorgt, wenn der Router nicht mehr erreichbar ist.

Anleitungen dafür gibt es wie Sand am Meer, ich habe - wenn ich mich Recht erinnere, auch in den SmartHome Hacks etwas dazu geschrieben. Einfach "watchdog raspberry pi" bei Google eingeben.

LG

pah

P.S.: Bitte nicht mit dem Alter kokettieren. Bei mir steht auch eine 6 am Anfang, und ich muss täglich Neues lernen.

Danke. Ich habe den WD schon auf dem FHEM-Pi laufen, aber wusste nicht, dass der auch für solche Aufgaben geht.

P.S.: Bitte nicht mit dem Alter kokettieren.

Ja, aber das ist halt wie im Sport, Dem Einen fällt es leichter, als dem Anderen. Einer liest etwas und hat verstanden und vergisst es nicht mehr. Beim Anderen hängt es halt erst nach dem 3. oder 4. Anlauf. Kann man also per Alter nicht ganz so gut vergleichen. Ich gebe mir auch Mühe und lerne auch täglich dazu. Bevor ich hierher kam, kannte ich Linux nur vom Namen her und FHEM war mir ebenfalls ein Rätsel. Meine Lernbereitschaft wird ja auch durch die Tatsache bewiesen, dass ich hier keine Frage zweimal gestellt habe.



@MadMax-FHEM
Sorry, hätte ich den Titel besser wählen sollen.

Was macht dich außer dem "er läuft ja ein paar Tage durch" so sicher, dass es nicht doch das WLAN-Sleep ist?
Lieber mal prüfen...

Habe ich nach Anleitung abgeschaltet und auch kontrolliert.

Ist alles die gleiche PI-HW

Die Pi sind unterschiedlich, was aber in diesem Fall ja gar nicht von Belang ist. Der Radio-Pi steht auch in der Fritzbox nicht mehr als aktiv. Er soll sich also selber booten. Da spielt ja der FHEM-Pi keine Rolle.
Die festen IPs habe ich ausschliesslich über die Fritzbox vergeben. Dazu habe ich "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen" angehakt.

@CoolTux
Vielen Dank, ich ausprobieren, ob das für meine Zwecke ausreicht, aber ich vermute, es wird genügen.


Dank an alle für die zahlreichen Antworten. Es wird etwas dauern (bis zum nächsten Ausfall), aber ich werde dann hier berichten.

[Invers]

Ich habe nun alles probiert.
Der Test mit dem Ping ging schief (hat nicht funktioniert). Der Radio-Pi steckte mit allen getesteten Versionen, die Ping abfragten, in einer Bootschleife. Sowohl hier im Forum, als auch im Internet wurde das ebenfalls festgestellt.

Im Anschluss habe ich den Code von CoolTux ausprobiert und bin begeistert. Nicht eine einzige Meldung zur Nichterreichbarkeit des Radio-Pi wurde ins Log geschrieben. Der Code funktioniert also zu 100 Prozent fantastisch.

Nochmal Dank an alle, auch für ihre Geduld und besonderen Dank an CoolTux.