Abstürze seit letztem oder vorletztem Update?

[M_I_B]

Hallo liebe Leute,

seit einigen Tagen, nach dem letzten oder vorletztem Update vor ca. 1 Woche, habe ich mindestens einmal am Tag das Problem, das sich der FHEM-eigene HTTPd verabschiedet. RaspBian selbst läuft weiter und FHEM kann per SSH wieder mit einem Restart zum Leben erweckt werden.
Was ich noch nicht habe feststellen können ist, ob FHEM an sich weiterhin läuft und seine Befehle abarbeitet oder nicht... Im fhem.log zumindest ist nicht die mindeste Auffälligkeit zu erkennen ...

Habe ich nur das Problem? Und wo könnte ich noch nach den Ursachen forschen?

[rudolfkoenig]

FHEM-eigene HTTPd verabschiedet

Ist damit FHEMWEB gemeint? Was heisst "verabschiedet"? Was heisst "FHEM kann per SSH wieder mit einem Restart zum Leben erweckt werden" genau? Falls FHEM komplett weg ist, und man keine Ahnug hat, in welchem Modul, dann hilft nur "attr global verbose 5".

[betateilchen]

habe ich mindestens einmal am Tag das Problem,

wieso "das" Problem? Du hast doch in den letzten Tagen nur solche komischen Sachen...

[M_I_B]

... Du hast doch in den letzten Tagen nur solche komischen Sachen...

WOW! Echt hilfreich! Das die Leutz immer was zu sagen haben, wenn sie nix zu sagen haben ...

... FHEMWEB gemeint? Was heisst "verabschiedet"? Was heisst "FHEM kann per SSH wieder mit einem Restart zum Leben erweckt werden" genau? Falls FHEM komplett weg ist, und man keine Ahnug hat, in welchem Modul, dann hilft nur "attr global verbose 5".

verbose 5 ist seit heute natürlich aktiv; warte jetzt nur auf Wiederholung ...
FHEMWEB ist weg, zumindest hat es den Anschein. Jedweder Aufruf endet in einem "Keine Verbindung zum Server". Ob FHEM dabei komplett den Schläfer macht, kann ich (noch) nicht sagen. Ein " /etc/init.d/fhem status" meldet zumindest "running". Sobald das Problem wieder auftaucht, kann ich hoffentlich mehr berichten.
Per SSH zum Leben erwecken meint, das ich dumpf FHEM neu starte via "/etc/init.d/fhem stop|start"

[Wernieman]

"weg" ist aber auch eine Sehr ausführliche Fehlermeldung.

Gehe mal vor nach folgender "Anleitung":
https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373

Ich glaube, ich sollte es mal ins WIKI "prügeln" .....

[M_I_B]

... gerade wieder passiert ...
Ich war im DashBoard auf einem TAB, welcher zwei Plots darstellt, welche ich mit F5 so alle paar Minuten aktualisiert habe. Von jetzt auf gleich war der FHEM-Server via HTTP nicht mehr erreichbar (Firefox kann keine Verbindung zu dem Server unter 192.168.1.199:8083 aufbauen.). Ein Zugriff per Telnet ist ebenfalls nicht mehr möglich (Verbindung abgewiesen). Ein "/etc/init.d/fhem status" via SSH sagt aus, das FHEM nicht läuft.
Per SSH und SMB- Freigabe kann ich weiterhin auf den Server zugreifen und konnte so das aktuelle Logfile (mit Verbose 5) herunterladen, was inzwischen 250mb groß ist.

Am Ende des Logfiles hätte ich nun irgend etwas erwartet, was auf den Fehler weist, aber leider ist dort noch nicht mal ansatzweise etwas in der Art zu erkennen.

Ich habe das Proto mal ab 09:50:02 beigefügt; der Ausstieg erfolgte im Zeitraum bis 09:53:00 ... Also ich sehe da nix...

EDIT: Zu viel Log... Ich habe es als Datei beigefügt

EDIT2:
Ich hatte jetzt das FHEM-Log wegen der Größe gerade auf täglichen Wechsel umgeschrieben und wollte das alte LOG in ein 7z packen... Dabei ist dann der komplette RPi abgeschmiert. Also irgend etwas ist da glunzig... Ich habe schon die Befürchtung, das nicht FHEM hier die Abstürze generiert, sondern nur sekundär daran beteiligt ist und durch eine (kurzzeitige) hohe Last den RPi aus dem Tritt bringt, welcher dann wiederum bestimmte Dienste killt (welche die Last erzeugt haben) oder wie in dem Fall gerade sich vollständig verabschiedet...

[rudolfkoenig]

Im FHEM-Log sehe ich auch nichts.
Kann man in "dmesg" was sehen? Laufen noch andere Dienste auf dem Rechner? Wieviel freien Speicher hat er?

[M_I_B]

... naja, ein paar andere Dienste laufen ja immer. Von mir wurde samba nachinstalliert und heute WiringPI, um damit dann einen Hardware-Watchdog ansteuern zu können...
Mit der Ausgabe von dmesg kann ich leider selbst nicht viel anfangen. Dazu fehlt mir Wissen, um daraus was ableiten zu können. Ich habe die Ausgabe mal in eine Datei umgeleitet und angehängt

[no_Legend]

mein cubie läuft auch nicht mehr stabil. Alle paar Stunden hängt dich fhem komplett auf.
In den Logs hab ich nichts gefunden.
Nur im kern.log hab ich was gefunden poste mal was da drin ist.

[M_I_B]

Nur im kern.log hab ich was gefunden poste mal was da drin ist.

... wenn Du mir verraten magst, wo genau ich das finde? Keinen Plan von Linux ...

[no_Legend]

Wenn du Linux hast
cat /var/log/kern.log

Schau mal ob du die gleiche Meldung bekommst wie ich:
https://forum.fhem.de/index.php/topic,55406.msg470660.html#msg470660

[M_I_B]

.... also wenn ich das richtig sehe, steht in "kern.log" genau das Selbe drin wie in der Ausgabe von "dmesg" ...
Solch eine Meldung wie die Deine habe ich nicht; da steht gar nichts mit Bezug zu FHEM drin...

[Wernieman]

Und ob ein Dienst läuft oder nicht, kannst Du 2gans schlecht" mit /etc/init.d/xxx sehen.

Besser ist da auf die Prozesse selber zusetzen, d.h.

Code Auswählen Erweitern

ps aux | grep [f]hem
siehe auch mein Beitrag etwas weiter "oben" ...

Wenn Du eine genaue Zeit des Absturzes weist, kannst Du auch die "üblichen Verdächtigen" des Systemes durchsuchen, d.h. einfach mal unter "/var/log" gucken, ob sich eine der Dateien in der Zeit geändert haben und WAS dort reingeschrieben wurde!

Code Auswählen Erweitern

ls -lha /var/log

[M_I_B]

... ok, da fehlen mir wie gesagt die Kenntnisse um zu wissen, das man via init.d nicht die selben Erkenntnisse erhält ...

Ich habe jetzt mal zum Spaß in diverse Logfiles reingesehen. Gehe ich recht in der Annahme, das [logfilename].1 der Vorgänger von [logfilename] ist und die eigentlich zeitlich fortgesetzt sein müssten? Denn auffällig ist bei einigen Logfiles zwischen dem File ohne "1" und mit "1" das Fehlen von 1-2 Tagen. Mag sein, das es normal ist, aber wie gesagt; nix Ahnung...

Ich werde die ganzen Logfiles mal wegsichern und aufräumen und dann mal auf den nächsten Abschmierer warten. Wenn das geschehen ist, werde ich die Logfiles erneut wegsichern, damit ich den Überblick behalte. Dann schaue ich mal, ob ich mit Eurer Hilfe da was finden kann...

[Wernieman]

Wenn Du (oder die Distri) das System so konfiguriert hast, da ja. Und wenn am Ende ein .gzu steht, wurden die alten Logfiles zusätzlich Komprimiert.

Da ich nicht weiß, wie Dein System (und Dein Logrotate) konfiguriert ist, bzw. in welchen Logfiles Du eine Lücke von "1-2 Tagen" hast, kann ich Deine Probleme nicht beurteilen.