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
/etc/init.d/fhem status sagt dass der FHEM läuft. Allerdings wenn ich
/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
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
ps alle Prozesse (auch fhem) auflisten müsste, aber da bekomme ich nur
Zitat
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
/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
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 ps aux | grep fhemherangehst, wirst Du sehen was so gerade läuft mit fhem im "Titel". Der Befehl 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?
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.
ps aux | grep fhem liefert
Zitatfhem 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
top liefert im Bezug auf fhem/perl nur
Zitat2108 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.
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
Zitat von: jensb am 02 August 2015, 12:03:51Wenn 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?
ZitatWenn 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
Zitat
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. :o
Grüße
ZitatWie finde ich heraus welche Module es unterstützen?
Commandref, pro Modul nachlesen, mit den Kommunikationsmodulen anfangen, also bei dir Homematic.
ZitatUnd 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"
ZitatIch 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.
Zitat... 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
1. Kleine Info zu ps:
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 ...
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 ... :o ... 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
grepe ml in der kern.log nach i/o Fehlern:
grep -i i/o /var/log/kern.log
bzw. eventuell auch mal in den alten:
zgrep -i i/o /var/log/kern.log*
Zitat von: Wernieman am 05 August 2015, 07:54:47
grepe ml in der kern.log nach i/o Fehlern:
grep -i i/o /var/log/kern.log
bzw. eventuell auch mal in den alten:
zgrep -i i/o /var/log/kern.log*
Nirgends ein entsprechender Eintrag vorhanden.
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
resolv.conf:
Zitatdomain 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?
Funktioniert JETZT denn der Pi oder nicht?
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.
Diagnose bei solchen Fehlern im Nachhinein sehr schwer möglich ....