FHEM auf PI läuft (scheinbar), aber ist nicht erreichbar

[marco-f]

Hi,

seit gestern Nachmittag erreiche ich den FHEM auf meinem Raspberry PI nicht mehr. Ich kann mich auf dem PI per SSH noch einloggen, eine Statusabfrage via

Code Auswählen Erweitern

/etc/init.d/fhem status sagt dass der FHEM läuft. Allerdings wenn ich

Code Auswählen Erweitern

/etc/init.d/fhem stop ausführe, bekomme ich zwar noch ein "Stopping fhem..." aber dann ist in der Konsole Schluß und ich kann nur irgendwann mit STRG-C abbrechen. Selbst ein

Code Auswählen Erweitern

sudo init 6 scheint zwar abgesetzt zu werden, aber es wird nicht ausgeführt, die Kiste läuft einfach weiter.

Wenn ich den PI Stromlos mache und neu starte kommt nach einem Restart das gleiche Verhalten heraus.

Ich hab gelesen dass mir ein

Code Auswählen Erweitern

ps alle Prozesse (auch fhem) auflisten müsste, aber da bekomme ich nur

  PID TTY          TIME CMD
2758 pts/0    00:00:01 bash
2773 pts/0    00:00:00 ps

gelistet, und nix von wegen FHEM. Auch ein erneuter Startversuch über

Code Auswählen Erweitern

/etc/init.d/fhem start ändert daran nichts.

Ich bin leider mit meinem bissel Linux Wissen schon am Ende. Wo kann ich jetzt mit der Fehlersuche weiter ansetzen?

Grüße,
Marco

[viegener]

Mit Deinen Angaben ist eine Diagnose nicht ganz einfach. Entscheidend wäre wie immer erstmal zu überlegen, was geändert wurde zwischen letztem funktionierenden Zustand und dem ersten Auftreten des Problems...

Das von Dir beschriebene Verhalten könnte auftreten, wenn irgendwo in fhem eine Endlosschleife entsteht.

Ein erster Ansatzpunkt wäre sicher mal der log file von fhem. Der ist natürlich auch über die Kommandozeile lesbar.
Wenn da nichts aussage kräftiges steht, kann man auch mit mehr logging (global verbose) versuchen mehr Infos zu finden.

Mit ps kannst Du so nicht viel erhalten, aber wenn Du mit

Code Auswählen Erweitern

ps aux | grep fhemherangehst, wirst Du sehen was so gerade läuft mit fhem im "Titel". Der Befehl

Code Auswählen Erweitern

top zeigt auch an, welche Prozess gerade wieviel cpu verbrauchen. Im Falle einer endlosschleife steht perl (und nicht fhem) ganz oben.

Vielleicht hilft das ja schon weiter?

[marco-f]

Geändert wurde gar nichts. Ich hab seit Wochen keine Änderung an der Config bzw. kein Update vorgenommen, kein neues Gerät eingetragen, kein anderes Netzteil eingesetzt o.ä. Der lief nur, bis gestern.

Logfile sagt nix auffälliges, da steht genau das drin was immer drin steht.

Code Auswählen Erweitern

ps aux | grep fhem liefert

fhem      2108 10.7  6.7  33812 30152 ?        S    09:23   1:43 perl fhem.pl fhem.cfg
root      2109  0.0  0.1   1696   560 ?        Ss   09:23   0:00 startpar -f -- fhem
pi        2383  0.0  0.1   5252   852 pts/0    S+   09:39   0:00 grep --color=auto fhem

Code Auswählen Erweitern

top liefert im Bezug auf fhem/perl nur

2108 fhem      20   0 34260  29m 3676 S   0.0  6.8   1:55.32 perl

Da sehe ich erstmal auch nix auffälliges. 0.0% Prozessorlast, 6.8% Speichernutzung

Nachdem ich jetzt im Browser wieder probiert habe mich im FHEM einzuloggen kam irgendwann plötzlich die Nutzer und Passwortabfrage, aber seitdem lädt der Browser weiter vor sich hin. Irgendwas scheint also irgendwie zu laufen.

[jensb]

Hallo marco-f,

kenne dieses Verhalten, wenn ein Modul in einen außergewöhnlichen Zustand kommt, hängen bleibt und die Kontrolle nicht wieder an FHEM zurück gibt.

Wenn das fhem Logfile keinen Hinweis gibt (was in solchen Fällen nicht ungewöhnlich ist) ist die Ursachenfindung u.U. nicht ganz einfach. Falls du die Möglichkeit hast und deine Module es unterstützen, versuche möglichst viele Module mit disable=1 zu deaktivieren und dann schrittweise zu reaktivieren.

Wenn du dabei zum Testen einen Neustart brauchst, ermittle mit "ps" wieder die PID, schieß das hängende FHEM mit "kill -s 9 <pid>" einfach ab, und starte es mit "/etc/init.d/fhem start" ganz normal.

LG, jensb

[marco-f]

Wenn das fhem Logfile keinen Hinweis gibt (was in solchen Fällen nicht ungewöhnlich ist) ist die Ursachenfindung u.U. nicht ganz einfach. Falls du die Möglichkeit hast und deine Module es unterstützen, versuche möglichst viele Module mit disable=1 zu deaktivieren und dann schrittweise zu reaktivieren.

Wie finde ich heraus welche Module es unterstützen? Und wo trage ich das disable=1 ein?

Wenn du dabei zum Testen einen Neustart brauchst, ermittle mit "ps" wieder die PID, schieß das hängende FHEM mit "kill -s 9 <pid>" einfach ab, und starte es mit "/etc/init.d/fhem start" ganz normal.

Wie ich im Eröffnungsbeitrag schon schrieb liefert mir ps nur

  PID TTY          TIME CMD
2459 pts/0    00:00:02 bash
2511 pts/0    00:00:00 ps

Ich bekomme keine FHEM PID die ich gezielt killen kann.

Ich war die letzten Stunden unterwegs ... irgendwann zwischendurch hatten die Widgets auf meinem Smartphone schonmal neue Daten erhalten, zu dem Zeitpunkt als ich das merkte waren die aber auch schon ne Stunde alt und gerade war wieder nix erreichbar. Durch Zufall stellte ich eben fest dass ich mich problemlos auf dem FHEM anmelden konnte. Aber nach 1-2 klicks und einem testweisen auslösen eines Homematic Schaltaktors ist wieder alles wie heut morgen.

Grüße

[jensb]

Wie finde ich heraus welche Module es unterstützen?

Commandref, pro Modul nachlesen, mit den Kommunikationsmodulen anfangen, also bei dir Homematic.

Und wo trage ich das disable=1 ein?

Wenn du die Weboberfläche nicht nutzen kannst, direkt in fhem.cfg eintragen mit anschließendem Neustart. Beispiel: "attr MyDisableSupportingDevice disable 1"

Ich bekomme keine FHEM PID die ich gezielt killen kann.

Verwende z.B. die Langversion aus dem vorherigen Post oder meine Lieblingsvariant "ps -ef | grep fhem". Habe nicht den ganzen Befehl angegeben, weil ich dachte, dass der Zusammenhang klar geworden wäre. Die PID ist die 1. Zahl in der Zeile in der auch "perl fhem.pl fhem.cfg" steht.

... nach 1-2 klicks und einem testweisen auslösen eines Homematic Schaltaktors ist wieder alles wie heut morgen

Klingt für mich fast so, als ob die Kommunikation mit der Homematic klemmt. Das HMLAN-Modul hat zwar kein dokumentiertes disable, aber dafür mehrere Diagnose-Readings "prot_...", die einen Hinweis geben könnten.

LG, jensb

[Wernieman]

1. Kleine Info zu ps:

Code Auswählen Erweitern

man ps

Ich würde zwar eher "ps -aux | grep fhem" machen, aber das ist Geschmacksache

2. Sicher Dir Dein FHEM-Verzeichnis (Backup ist immer gut)(und s.u.)

3. Da scheinbar bei dir HM klemt, würde ich persönlich (nach dem Backup s.o,) mal die HM Komponenten aus der CFG rausschmeisen und gucken, ob dann fhem läuft. Es könnte Dir zwar die Konfig zerschiesen, aber Du hast doch Backup? (s.o.)

Wenn dann FHEM läuft, kannst Du Top/Down die HM Komponenten wieder reinnehmen ...

[marco-f]

Hi,

ich habe in der Config Stück für Stück sämtliche Kommunikationsmodule auskommentiert. Daraufhin lief FHEM ein bisschen schneller, aber besonders die Weboberfläche reagierte immer noch viel zu träge (und das ohne dabei Prozessorlast zu erzeugen). Da ich dann am Abend angekommen war und eigentlich erstmal schnell wieder ein lauffähiges System haben wollte, nahm ich eine andere SD-Karte und spielte da ein Backup auf und brachte das System so fürs erste wieder ans laufen. Gestern wollte ich dann noch ein wenig an dem rumzickenden nach dem Fehler System suchen. Speicherkarten wieder getauscht ... ... das System rannte wieder. Daraufhin hab ich die Kommunikationsmodule wieder in Betrieb genommen und es rennt weiterhin. Im Augenblick vermute ich der Fehler lag irgendwie an der Speicherkarte, was aber heißt er kommt sicher wieder.

Grüße

[Wernieman]

grepe ml in der kern.log nach i/o Fehlern:

Code Auswählen Erweitern

grep -i i/o /var/log/kern.log

bzw. eventuell auch mal in den alten:

Code Auswählen Erweitern

zgrep -i i/o /var/log/kern.log*

[marco-f]

grepe ml in der kern.log nach i/o Fehlern:

Code Auswählen Erweitern

grep -i i/o /var/log/kern.log

bzw. eventuell auch mal in den alten:

Code Auswählen Erweitern

zgrep -i i/o /var/log/kern.log*

Nirgends ein entsprechender Eintrag vorhanden.

[Prof. Dr. Peter Henning]

Evtl. mal beim Pi einloggen und den Inhalt von /etc/resolv.conf checken. Ping auf eine Netzwerkadresse, z.B. ping www.fhem.de. Könnte - soweit das aus den eher dürren Information zu vermuten ist - ein Nameserver-Problem sein. Ist aber eher aus der Hüfte geschossen.

LG

pah

[marco-f]

resolv.conf:

domain fritz.box
search fritz.box
nameserver 192.168.0.1

Ping läuft problemlos, auf sämtliche Adressen. Und geändert hab ich an der FritzBox nix. Wenn ich mich lokal auf dem Raspberry über die IP Adresse einlogge, da braucht der doch keinen Nameserver. Oder doch!?

Welche Info's wäre denn noch von Bedeutung?

[Wernieman]

Funktioniert JETZT denn der Pi oder nicht?

[marco-f]

Er läuft JETZT, auf der ursprünglichen Hardware in der ursprünglichen Konfiguration. D.h. aktuell kann ich nur in alten Log's schauen ob ich Auffälligkeiten finde.

[Wernieman]

Diagnose bei solchen Fehlern im Nachhinein sehr schwer möglich ....