Tipps fürs debuggen gesucht - fhem hängt sich auf

[Elektrolurch]

Hallo,

meine Instalation läuft jetzt schon seit längerem recht stabil (Heizungsanlage, Thermostate, Licht, Rolläden). Hin- und wieder verbessere ich noch was oder bau was an. Nun habe ich seit einigen Tagen unerklärliche Abstürze.
Die Ports der Webinstanzen sind noch offen, fhem reagiert aber nicht mehr.
Der Prozess (./startfhem) läuft zwar noch, lässt sich aber nur mit kill -9 beenden.
Es gibt keine Fehlereintragungen im log. Habe verbose schon mal hoch gesetzt.
Zuerst habe ich meine letzte Änderung im Verdacht gehabt. Hier wird bei Überschreiten einer bestimmten einstellbaren Temperatur im Pufferbehälter der Solaranlage die Umwälzpumpe der Heizung eingeschaltet und das Thermostat im Hobbyraum auf 21 Grad gestellt.
Ich habe im notify der Heizungsanlage das log eingeschaltet, aber die Bedingung wird gar nicht angesprungen, da zum Zeitpunkt des Absturzes nicht erfüllt.
Neu ist noch das Modul 70_stv, welches mir bei einem eingehenden Anruf eine Meldung auf dem TV ausgibt.
Aber auch das hat schon mehrfach funktioniert.
Für mich sieht das so aus, dass fhem irgendwo auf einen System-Call wartet.
Gibt es da eine Möglichkeit herauszufinden, wo fhem bzw. perl gerade steht?
Zum Beispiel die Ausgabe des Prozedurenstacks?

Die Heizungsanlage wird im übrigen mit den ttputils im nonblocking Mode ausgelesen, einmal pro Minute. Läuft ohne jede Probleme.

Gruß


Elektrolurch

[P.A.Trick]

Hast du bei dem 70_STV Modul die fork-Option gesetzt?
Was ist der letzte fhem.log Eintrag?
Auf welchen System läuft dein FHEM?

[Puschel74]

Hallo,

Auf welchen System läuft dein FHEM?

Es gibt auch FHEM-ler mit Signaturen 

Auf einer 7390 betreibt Elektrolurch sein FHEM.

Grüße

Edith. ja ich weiß - es gibt auch FHEM-ler die sich Signaturen nicht durchlesen können weil sie nicht angezeigt werden.

[P.A.Trick]

Arghhhh ja das vergesse ich immer Nun, es bleiben aber zwei Fragen offen

[Puschel74]

Hallo,

klar bleiben noch 2 Fragen offen.
Du hast dir aber seine Signatur schon angeschaut?

Grüße

[Elektrolurch]

Hallo,

ja, FB7390.
Nein, beim stv habe ich derzeit überhaupt keine Attribute gesetzt. Genaugenommen hatte ich es schon vor einem Jahr mal testhalber eingebunden, lief aber nicht, weil ich es in der Definition mit Angabe des Portes 62235 definiert hatte. Im Code des Moduls ist / war aber ein Bug, man darf den Port nicht angeben, wenn man den 62235 haben möchte. Das hatte ich vor ein paar Tagen festgestellt und geändert. Seit dem läuft es, aber ausführlich noch nicht getestet. Konnte alerdings noch nicht feststellen, ob zum Zeitpunkt des Absturzes überhaupt ein Telefonanruf einging und stv genutzt wurde.
Meine unix-Zeiten sind schon lange her, aber es gab da mal was, mit kill und einer Nummer an den Prozess den Prozedurstack ausgeben zu lassen.
Ob das mit perl geht, weiß ich nicht.
Jedenfalls scheint perl auf irgend etwas zu warten, Schleifen habe ich in meinem Code nicht, auch nicht über notifys die ggfs wieder ein notify triggern, dann stände das im log.
Der letzte Eintrag im log sagt nur, dass die HzAnlage (Gasbrenner) - Werte ausgelesen wurden und nach Verarbeitung die "Update-Zeit" (ein reading der Hz, welches ich mir zur Kontrolle anzeigen lasse) aktualisiert wurde. Passiert einmal je Minute.
Darin kann also kein "Absturz" oder "Hängenbleiben" programmiert sein.

Gruß


Elektrolurch

[P.A.Trick]

Hm....ja Puschel ich habe gelesen, dass ich keine Farben nutzen soll!

Zurück zum Problem: Ich wüßte jetzt auch nicht, wie man den Perl Stack debuggen kann.
Wie sehen denn die Filesysteme aus, ist vielleicht die Fritzbox voll?

[Elektrolurch]

Da ist Platz genug auf der Box, da ich von Zeit zu Zeit auch die alten debugs lösche.
Habe gerade nachgesehen: Zum Zeitpunkt des "Hängenbleibens" ist tatsächlich ein Anruf eingegange, der hatte keinen aufgelösten Namen. In dem stv-Modul werden da ohne Prüfung immer eine feste Anzahl von Parameter (set-befehl) kopiert. Da steht dann wohl ein undef mitten drin und der aufgerufene Socket kommt wohl nicht damit zurecht.
Zumindest könnte dies das Problem erklären....

Gruß

Elektrolurch

[P.A.Trick]

Deaktive doch mal das Modul und rufe bei dir zuhause an!

[Elektrolurch]

Geht nicht. Das ganze scheint nur dann "hängenzubleiben", wenn der Anrufernamen nicht ermittelt werden kann. Damit scheint das 70_stv ein Problem zu haben, der Code fragt jedenfalls nicht ab, ob da ein "undef" drin steht.

[justme1968]

du kannst doch die rufnummer unterdrücken.

gruss
  andre

[Elektrolurch]

Stimmt. Danke.
Mir gings eigentlich ja auch ums prinzipielle, d.h. einen Aufrufstack zu bekommen. So was gabs in C, wenn man beim Kompilieren die Symbole mit eingebunden hat.
So ein Problem, wie oben geschildert, kann ja immer mal auftreten...
Ich denke, dass es an dem 70_stv Modul liegt. Der Code im set-Befehl kopiert anscheinend eine feste Zahl von Parametern, ohne zu prüfen, ob die undef sind. Und möglicherweise mag dann der Aufruf an den Socket die Daten nicht. Aber das müsste ich mir erst einmal genauer ansehen. Habe erst einmal ein paar Workarrounds eingebaut....

[rudolfkoenig]

Google spuckt eigentlich schnell was aus, was auf einem FB7390 (gerade getestet) funktioniert:

Code Auswählen Erweitern

# cat t.pl
use Carp qw<longmess>;
sub fn3() { print longmess(); }
sub fn2() { fn3(); }
sub fn1() { fn2(); }
fn1();

# perl t.pl
at t.pl line 3
        main::fn2() called at t.pl line 4
        main::fn1() called at t.pl line 5


Fuer Leute die sich mit Unix besser auskennen (oder viel Zeit haben) kann http://fhem.de/fb7390/strace auch helfen.

[Elektrolurch]

Hallo,

leider habe ich immer noch das Problem, das fhem manchmal drei Tage, manchmal nur einige Stunden durchläuft und dann hängen bleibt (s.o.).
Was kann ich derzeit ausschließen:
1. Speicherplatz ist genügend frei auf der Box.
2. longpoll habe ich für die Web-Instanzen deaktiviert.
3. Wenn fhem hängen bleibt, sind keine Verbindungen zum Webserver oder telnet offen.
4. Wenn fhem hängen bleibt, zeigt strace keine Prozeduraufrufe an.
5. Ich habe jetzt fhem mit strace über drei Tage laufen lassen und zwischenzeitlich immer wieder das log wg. Plattenplatz gelöscht, da blieb fhem nicht hängen.
6. Das Modul STV kann ich definitiv ausschließen, da der Hängenbleiber auch bei deaktiviertem device auftritt (s.o. mein Verdacht)
7. Auf der FB verwende ich derzeit OS 6.03, welches schon seit Monaten läuft, genauso wie die fhem-Software. Das unregelmässige Hängenbleiben von fhem tritt aber erst seit ca. 3 Wochen auf. Grundsätzliche Codeergänzungen habe ich aber in den letzten Wochen nicht gemacht.
Über entsprechende Log-File Ausgaben habe ich überprüft, ob sich da ev. doch eine Endlosschleife über notify - setreading oder ähnliches ergeben haben könnte: negativ.
Die Hängenbleiber sind auch mit keinem Event zu korrellieren.
8. Ich habe mal eine Routine geschrieben, die im fehm-Baum die Werte, readings usw. auf undefs überprüft. Dabei ist mir aufgefallen, dass das fht-Modul, durch das Umbenennen des devices wohl etwas Probleme mit den automatisch angelegten logs und plots hat. (logfile -> interne Variable nr wird beim save als undef bemeckert). Daher habe ich mal vorsichtshalber die plots und logs zu den fht-devices gelöscht. Brachte aber auch kein Ergebnis.


Derzeit habe ich einen Workaround gebastelt:
fhem schreibt über ein "at" alle 10 Minuten einen Zeitstempel in eine Datei. Ein kleines Skript prüft den Inhalt dieser Datei alle 10 Minuten. Ist der Zeitstempel älter, wird die pid von fhem ermittelt und der Prozeß gekillt und dann ./startfhem& aufgerufen.
Leider löst das nicht das Problem.
Hat jemand eine Idee, was man noch prüfen könnte? Oder wie man das Problem weiter einkreisen könnte?

Ich habe zwar noch einige Backups von fhem seit dem 2.5.2014 und könnte diese zurückspielen, dann weiß ich aber immer noch nicht, was die Ursache für das Problem sein könnte.

Gruß

Schnief, schnief

Elektrolurch

[rudolfkoenig]

Ich wuerde FHEM mit "attr global verbose 5" laufen lassen, und falls es wieder haengen bleibt, hier die letzten 50-100 Zeilen aus dem Log posten.
Man muss in dieser Zeit den Plattenplatz ueberwachen, und notfalls logfile wechseln (attr global filelog <neue-dateiname>), damit man die alte Datei loeschen kann.