Seit meiner letzten Update Runde von FHEM und der Raspian Distri stürzt FHEM sporadisch kommentarlos ab.
In der Log findet sich leider keinerlei Hinweis. Wenn ich mit Top auf dem System nachschaue taucht dort auch kein Perl mehr auf.
Starte ich den Dienst wieder läuft alles wie es soll. Nach einer Stunde oder irgendwann passiert das gleiche wieder.
Wo kann ich bei der Fehlersuche starten?
Ich verwende RaspberryPI frisch auf Debian buster aktualisiert. FHEM ist aktuell. Großteil der Geräte ist über KNX mit KNXD angebunden.
Der letzte LOG Eintrag der vorhanden ist liefert keine Hinweise, mal Kalendermodul, mal Sonos Statusmeldungen ohne Fehler.
Was liefern auf der Console denn
systemctl status fhem
und (Datum und Zeit entsprechend des Zeitraums des vermuteten Absturzes anpassen)
journalctl --since "2021-06-01 01:00" --until "2021-06-01 03:00"
?
pi@hcs:~ $ systemctl status fhem
● fhem.service - LSB: FHEM server
Loaded: loaded (/etc/init.d/fhem; generated)
Active: active (exited) since Tue 2021-06-01 08:20:58 CEST; 4h 49min ago
Docs: man:systemd-sysv-generator(8)
Process: 640 ExecStart=/etc/init.d/fhem start (code=exited, status=0/SUCCESS)
in der Zeit ist es aber sicher 2x abgestürzt und ich habe es mit sudo /etc/init.d/fhem start gestartet. Ich starts dann in Zukunft wohl besser mit systemctl
Dementsprechend hat das Log auch nichts geliefert.
init!? ???
Auf buster läuft doch per default systemd, warum hast du fhem dort mit dem init Startsystem laufen?
Und
journalctl --since "2021-06-01 08:20" --until "now"
liefert nichts, was auf einen FHEM crash hindeuten könnte?
Auch keine Auszüge aus dem FHEM-log?
Dann würde ich sagen, verbose global auf 5 und schauen, was kurz vor dem Absturz passiert...
ich hab fhem schon länger auf dem System am laufen (geschätzt 3 Jahre) unsprünglich war das noch eine andere Distribution.
D.h. ich hab das ursprüngliche Startsystem am laufen.
Journalctl liefert nichts, aber systemctl status sagt ja das es schon länger läuft, vermutlich weil das Startsystem ein anderes ist?
Nein FHEM Log ist unauffällig, jedes mal ist der letzte Eintrag ein anderer.
Hab jetzt global verbose jetzt erstmal auf 4 hoch
nutze deine kostbare energie effektiv und mach besser zuerst einen umbau auf systemd. ;)
bin ich gerade dabei :)
für den Fall das es jemand sucht
https://forum.fhem.de/index.php?topic=54271.0 (https://forum.fhem.de/index.php?topic=54271.0)
Dateiinhalt der fhem.service von hier
https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file) (https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file))
kannst du den Zeitraum eingrenzen wann Fhem abstürzt? Schau mal ob du in den systemlogs nach ob da irgend was mit fhem, perl zu finden ist ... /var/log/syslog, /var/log/daemon, var/log/messages ...
Am besten gleich nachdem Fhem "verschwindet". Dann siehst du am Änderzeitpunkt in welchem Log was drin sein könnte.
Ansonsten ist es schwer was zu finden wenn es überhaupt keine Logs gibt ...
Zitat von: andi11 am 01 Juni 2021, 13:42:11
bin ich gerade dabei :)
für den Fall das es jemand sucht
https://forum.fhem.de/index.php?topic=54271.0 (https://forum.fhem.de/index.php?topic=54271.0)
Dateiinhalt der fhem.service von hier
https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file) (https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file))
Warum nicht einfach neu aufsetzen auf aktuellem OS!!?
Übt/prüft gleich, ob deine Backup/Restore Methode (die du hoffentlich hast!) funktioniert ;)
Also SD aufheben, neue SD mit neuem OS aufsetzen (weil irgendwas kommt als nächstes, wenn das OS zu alt ist: ssl, alexa-fhem, ...) fhem installieren (debian.fhem.de -> the easy way / dann ist autom. systemd :) ) und Backup einspielen...
Du kannst fhem auch im Debug-Modus von Console starten, dann siehst du genau was passiert ist, bevor es abgestürtz ist.
Und: selbst wenn du nichts siehst wäre es u.U. hilfreich zu posten was im fhem Log steht und zwar eben jeweils (kurz be)vor Server-Start: including fhem.cfg
U.U. auch hilfreich:
https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche
Gruß, Joachim
Zitat von: yersinia am 01 Juni 2021, 13:08:32
Was liefern auf der Console denn
systemctl status fhem
und (Datum und Zeit entsprechend des Zeitraums des vermuteten Absturzes anpassen)
journalctl --since "2021-06-01 01:00" --until "2021-06-01 03:00"
?
danke für deinen Hinweis. Nach Wechsel auf Sytemctl komm ich der Sache auf die Spur. Beim Absturz gerade eben zeigt journalctl zuerst knxd und dann task kworker blocked for more than 120sec beim Zugriff auf die SD Karte (vermutlich)
Mal genauer verfolgen....
Da die SD Card älter ist ...und Du sowieso am "migrieren", mal dran gedacht die Karte auszutauschen?
Gerade bei unspezifischen Problemen haben wir hier relativ häufig SD-Card Probleme diagnostizieren können.
Hinweis:
Habe selber mal eine Defekte in der Firma gehabt. Selbst ein fsck hat keine Probleme gezeigt, erst als ich sie "neu" "formatieren/partitionieren" wollte, war es eindeutig (Gab hier im Forum irgendwo ein Thread dazu). Nur mal als Gedanke.
die SD Karte werde ich auf jeden Fall wechseln.
Das nervigste was ich jemals am Raspi hatte war dass das OS die Karte auf readonly gesetzt hatte aber man in FHEM usw davon nix mitgekriegt.
FHEM Änderung => Neustart => Änderung weg => häää wo ist das hin? => Änderung => Neustart usw usw usw
Bei vielen Distris ist das Root Dateisystem genau so eingebunden. Damit das System weiterläuft, auch bei defekten Dateisystem. Da Unix Standardmäßig cached *), ist damit immer auch temporäres "Schreiben" möglich
*)
Tiefere Erläuterung für "Ägschberden"
Eigentlich cached Unix nicht, sondern schreibt Grundsätzlich in den "freien" Speicher, der vom System im 2. Prozess auf die Platte geschrieben wird. Anders als Windows, welche die Plattenzurgiffe auf einen Chache umbiegt. Hört sich erstmal als Akademischer Unterschied an, hat aber Systemtechnisch Unterschiede, welche sich in Effekten wie diesen widerspiegelt.
macht finde ich auch Sinn. Schade nur das ich es nicht mitbekommen habe.
ich hab jetzt dank eurer Tipps:
Auf systemctl umgestellt
SD Karte erneuert
KNXD auf knxd.ini umgestellt
zur Sicherheit Freezemon aktiviert
herausgefunden dass nicht FHEM einfriert, sondern der komplette Raspi => ich setz diesen Thread auf erledigt, da es wenn dann vermutlich nicht an FHEM liegt.
Vielen Dank
herausgefunden dass nicht FHEM einfriert, sondern der komplette Raspi
Stomversorgung geprüft?
Was sind die letzten Meldungen in den Üblichen Verdächtigen des Pis?
syslog/kernlog etc.
Es gibt keine Abstürze mehr. SD Karte und KNXD waren wohl die Ursachen
aber ehrlich gesagt: Zusammenlegung von NAS und RaspberryPI in einem neuem Server ist der nächste Schritt ;D
Weg von SD-Karten wäre auch ein guter nächster Schritt ;-)
den ich mit dem neuen Server auch gegangen bin. Ich wechsel auf SSD.
Natürlich könnte ich mir auch einen USB SSD Stick kaufen, das ist für mich aber gefühlt gebastel.
Alternativ geht natürlich auch ein Aufsatz für den Raspi, aber dann passt dieser nicht mehr in mein Hutschienengehäuse.