Hallo,
ich habe eine seit 5 Jahren ansich stabil laufende FHEM Installation auf einem Raspi3, doch seit ein paar Tagen stürzt FHEM - vermutlich - um oder ggen Mitternacht ab. Man merkt das morgens nach dem Aufstehen dass sich keine Lichter mehr schalten lassen, und die Weboberfläche nicht mehr erreichbar ist. Ich logge mich dann per SSH auf dem Raspi ein, mache einen sudo reboot, und alles läft wieder wie normal, bis Mitternacht.
Hier mal die letzten Einträge im Log, man sieht schön den Zeitsprung gegen 24:57 auf kurz nach 5 Uhr heute(Zeitpunkt des Neustarts).
2025.05.08 23:28:00 1: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 reappeared (WPCounterArduinoClass)
2025.05.08 23:31:20 1: /dev/ttyUSB2 disconnected, waiting to reappear (TCM_ESP2_2)
2025.05.08 23:31:20 3: Setting TCM_ESP2_2 serial parameters to 115200,8,N,1
2025.05.08 23:31:20 1: /dev/ttyUSB2 reappeared (TCM_ESP2_2)
2025.05.08 23:31:22 3: TCM TCM_ESP2_2 set reset
2025.05.08 23:31:25 2: TCM TCM_ESP2_2 Timeout reading response for get reset
2025.05.08 23:31:25 3: TCM TCM_ESP2_2 get baseID
2025.05.08 23:31:27 2: TCM TCM_ESP2_2 Timeout reading response for get baseID
2025.05.08 23:31:27 2: TCM TCM_ESP2_2 initialized
2025.05.08 23:34:40 1: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 disconnected, waiting to reappear (WPCounterArduinoClass)
2025.05.08 23:34:40 3: Setting WPCounterArduinoClass serial parameters to 115200,8,N,1
2025.05.08 23:34:41 1: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 reappeared (WPCounterArduinoClass)
2025.05.08 23:38:00 1: /dev/ttyUSB2 disconnected, waiting to reappear (TCM_ESP2_2)
2025.05.08 23:38:00 3: Setting TCM_ESP2_2 serial parameters to 115200,8,N,1
2025.05.08 23:38:00 1: /dev/ttyUSB2 reappeared (TCM_ESP2_2)
2025.05.08 23:38:02 3: TCM TCM_ESP2_2 set reset
2025.05.08 23:38:05 2: TCM TCM_ESP2_2 Timeout reading response for get reset
2025.05.08 23:38:05 3: TCM TCM_ESP2_2 get baseID
2025.05.08 23:38:07 2: TCM TCM_ESP2_2 Timeout reading response for get baseID
2025.05.08 23:38:07 2: TCM TCM_ESP2_2 initialized
2025.05.08 23:41:20 1: /dev/ttyUSB2 disconnected, waiting to reappear (TCM_ESP2_2)
2025.05.08 23:41:20 3: Setting TCM_ESP2_2 serial parameters to 115200,8,N,1
2025.05.08 23:41:20 1: /dev/ttyUSB2 reappeared (TCM_ESP2_2)
2025.05.08 23:41:23 3: TCM TCM_ESP2_2 set reset
2025.05.08 23:41:25 2: TCM TCM_ESP2_2 Timeout reading response for get reset
2025.05.08 23:41:25 3: TCM TCM_ESP2_2 get baseID
2025.05.08 23:41:27 2: TCM TCM_ESP2_2 Timeout reading response for get baseID
2025.05.08 23:41:27 2: TCM TCM_ESP2_2 initialized
2025.05.08 23:44:41 1: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 disconnected, waiting to reappear (WPCounterArduinoClass)
2025.05.08 23:44:41 3: Setting WPCounterArduinoClass serial parameters to 115200,8,N,1
2025.05.08 23:44:41 1: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 reappeared (WPCounterArduinoClass)
2025.05.08 23:46:09 1: Timeout for VIERA_GetDoIt reached, terminated process 31215
2025.05.08 23:46:09 2: WohnzimmerTV [NonBlocking-VIERA_GetAbortFn()]: BlockingCall for WohnzimmerTV was aborted, timeout reached
2025.05.08 23:46:49 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.178.49_60822/awtrix_2c3584 left us (keepalive check)
2025.05.08 23:48:01 1: /dev/ttyUSB2 disconnected, waiting to reappear (TCM_ESP2_2)
2025.05.08 23:48:01 3: Setting TCM_ESP2_2 serial parameters to 115200,8,N,1
2025.05.08 23:48:01 1: /dev/ttyUSB2 reappeared (TCM_ESP2_2)
2025.05.08 23:48:04 3: TCM TCM_ESP2_2 set reset
2025.05.08 23:48:06 2: TCM TCM_ESP2_2 Timeout reading response for get reset
2025.05.08 23:48:09 3: TCM TCM_ESP2_2 get baseID
2025.05.08 23:49:04 2: TCM TCM_ESP2_2 Timeout reading response for get baseID
2025.05.08 23:49:25 2: TCM TCM_ESP2_2 initialized
2025.05.08 23:49:25 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.178.46_54977/awtrix_52a958 left us (keepalive check)
2025.05.08 23:49:25 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.178.49_60823/awtrix_2c3584 left us (keepalive check)
2025.05.08 23:53:39 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.178.46_54982/awtrix_52a958 left us (keepalive check)
2025.05.08 23:54:46 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.178.49_60828/awtrix_2c3584 left us (keepalive check)
2025.05.08 23:55:00 3: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 31773
2025.05.08 23:55:00 1: [FritzBox | 6660 | 252.07.58 | Readout_Aborted.6353] - ERROR:Error: Timeout when reading Fritz!Box data. 285 | BlockingKill
2025.05.08 23:55:01 1: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 disconnected, waiting to reappear (WPCounterArduinoClass)
2025.05.08 23:55:01 1: Timeout for VIERA_GetDoIt reached, terminated process 31799
2025.05.08 23:55:01 2: WohnzimmerTV [NonBlocking-VIERA_GetAbortFn()]: BlockingCall for WohnzimmerTV was aborted, timeout reached
2025.05.08 23:55:02 3: Setting WPCounterArduinoClass serial parameters to 115200,8,N,1
2025.05.08 23:55:02 1: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 reappeared (WPCounterArduinoClass)
2025.05.08 23:57:37 2: deCONZ: http request failed: read from http://192.168.178.142:80 timed out
2025.05.08 23:57:37 3: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 31821
2025.05.08 23:57:37 1: [FritzBox | 6660 | 252.07.58 | Readout_Aborted.6353] - ERROR:Error: Timeout when reading Fritz!Box data. 285 | BlockingKill
2025.05.09 05:07:56 1: Including fhem.cfg
2025.05.09 05:07:57 3: Opening Stromzaehler device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AD0JFX9R-if00-port0
2025.05.09 05:07:57 3: Setting Stromzaehler serial parameters to 9600,8,N,1
2025.05.09 05:07:57 3: OBIS (Stromzaehler) - Init done
2025.05.09 05:07:57 3: Stromzaehler device opened
2025.05.09 05:08:01 3: telnetPort: port 7072 opened
2025.05.09 05:08:01 3: WEB: port 8083 opened
2025.05.09 05:08:01 3: WEBphone: port 8084 opened
2025.05.09 05:08:01 3: Opening Denon device 192.168.178.73:23
Die Frage ist nun: wie finde ich heraus, was das Beenden bzw. den Absturz verursacht? Habt ihr da irgendwelche Ideen? Vielen Dank!
Hm,
Du hast zunehmende Fehler bei Modulen, die Netzwerkanfragen durchführen.
Allerdings bei 5 Jahren könnte es auch ein Seiteneffekt einer schwächelnden SD-Karte sein. Eine andere Frage nach 5 Jahren. Wie viel Platz ist denn noch frei auf der SD-Karte?
Grüße Jörg
..doppelt genäht hält vielleicht besser - war auch schon fertig...
Zitat von: Jackie am 09 Mai 2025, 06:58:57was das Beenden bzw. den Absturz
Sieht eigentlich nicht so aus, als wäre FHEM abgestürzt, eher "blockiert".
Da vorher einige Netzwerkprozesse zu hängen scheinen (und v.a. wohl dann auch die Fritte als dns-Dienst nicht erreichbar ist!), würde ich eher da suchen -und ggf. heute nach Mitternacht erst mal schauen, ob FHEM tatsächlich "abgestürzt" ist, oder eben noch läuft... (https://wiki.fhem.de/wiki/Hilfe!_Mein_FHEM_funktioniert_nicht!)
Wenn es wirklich abgestürzt wäre, sollte es eigentlich via systemd neu gestartet werden - da bitte auch die Einstellungen checken.
Davon unabhängig solltest du mal deine USB-Schnittstellen-Definitionen anschauen - esc scheint zwei Dongles zu geben mit gleicher ID, von denen aber nur eines "by-id" angegeben ist. Verwende hier einheitlich für diese zwei "by-path" (im Wiki suchen, wenn es unklar ist).
2025.05.08 23:28:00 1: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 reappeared (WPCounterArduinoClass)
2025.05.08 23:31:20 1: /dev/ttyUSB2 disconnected, waiting to reappear (TCM_ESP2_2
Hallo,
danke für die Antworten. Die SD Karte (16GB Sandisk) habe ich erst vor wenigen Monaten gegen eine Samsung Evo Pro mit 128GB getauscht und die Partition entsprechend vergrößert, davon sind ca. 12 Prozent belegt (df). Kann ich die Karte irgendwie auf Fehler untersuchen.
Warum hier Probleme bei Netzwerkanfragen auftreten ist mir noch nicht so ganz klar, das Problem der doppelten USB Adapter (verwaister Eintrag) habe ich gefunden und behoben.
Was genau sollte denn in systemd stehen, wie prüfe ich das ob der automatische fhem restart korrekt eingerichtet ist?
Auffällig ist halt, dass nach 23:57h gar keine Logeinträge mehr kommen...
Hi,
zeig doch mal die Ausgabe von:
sudo systemctl cat fhem.service
bzw. schau hier nach Auffälligkeiten
sudo journalctl -u fhem.service
Gruß Otto
Hallo Otto,
klar, hier die Ausgaben:
pi@fhem:~ $ sudo systemctl cat fhem.service
# /run/systemd/generator.late/fhem.service
# Automatically generated by systemd-sysv-generator
[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/fhem
Description=LSB: FHEM server
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=remote-fs.target
[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/fhem start
ExecStop=/etc/init.d/fhem stop
pi@fhem:~ $
und
pi@fhem:~ $ sudo journalctl -u fhem.service
-- Logs begin at Fri 2025-05-09 08:21:50 CEST, end at Fri 2025-05-09 09:57:13 CEST. --
May 09 08:21:56 fhem systemd[1]: Starting LSB: FHEM server...
May 09 08:22:01 fhem fhem[586]: Starting fhem...
May 09 08:22:04 fhem systemd[1]: Started LSB: FHEM server.
pi@fhem:~ $
Ist da irgendwas auffällig?
Zitat von: Jackie am 09 Mai 2025, 09:57:49Ist da irgendwas auffällig?
Nun ja, "Restart=no" sagt doch schon alles...
Bei mir steht "always".
Ja :)
Zitat# Automatically generated by systemd-sysv-generator
Du hast noch init.d Kompatibilitäts Modus am Laufen, ev. deshalb steht im Journal nicht wirklich viel.
was sagt
cat /etc/os-releaseZitatWas genau sollte denn in systemd stehen, wie prüfe ich das ob der automatische fhem restart korrekt eingerichtet ist?
Man könnte das mal umstellen https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file) aber das ist nicht die Lösung für Dein Problem. Insofern lass uns erstmal nach der Ursache suchen.
Hier die Ausgabe von
pi@fhem:~ $ sudo cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
pi@fhem:~ $
Wie stelle ich denn den Restart auf always um? Danke für eure Tipps
Würde das nicht mehr reparieren, sondern neu installieren: https://www.heise.de/news/Debian-10-am-Lebensende-angekommen-9784927.html
Zitat von: Jackie am 09 Mai 2025, 10:15:59Wie stelle ich denn den Restart auf always um?
naja eigentlich indem Du die service unit die automatisch erzeugt wurde, gegen die "ordentliche" im Wiki austauschst ;)
Oder halt: backup fhem, neues OS, fhem neu installieren, restore fhem
Und natürlich die debian Pakete installieren, falls Du nicht sicher bist was Du alles installiert hast:
https://heinz-otto.blogspot.com/2019/07/infos-zur-installation-von-modulen-und.html
So ich hab jetzt den service umgestellt, jetzt startet fhem beim Systemstart gar nicht mehr. Manuell kann ich nur per Commandline starten:
pi@fhem:~ $ /etc/init.d/fhem start
Starting fhem...
Can't open ./log/fhem-2025-05.log: Permission denied at fhem.pl line 2948.
pi@fhem:~ $ sudo /etc/init.d/fhem start
Starting fhem...
pi@fhem:~ $
Kann ich das irgendwie debuggen wo der Fehler liegt?
wo hast DU die service unit hingelegt? hast Du sie aktiviert (systemctl enable ...)?
Zitat von: Otto123 am 09 Mai 2025, 11:46:18wo hast DU die service unit hingelegt? hast Du sie aktiviert (systemctl enable ...)?
So hab ich es probiert:
pi@fhem:~ $ sudo systemctl edit --full fhemDann alles gelöscht und die Vorlage aus dem Wiki eingefügt.
Dann:
pi@fhem:~ $ sudo systemctl enable fhem
Synchronizing state of fhem.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable fhem
Created symlink /etc/systemd/system/multi-user.target.wants/fhem.service → /etc/systemd/system/fhem.service.
pi@fhem:~ $
Und anschließend neu gestartet
und das startet nicht?
systemctl status fhemund
journalct -u fhem.service
Ich habe das so noch nie umgestellt, muss man ev. das Script in /etc/init.d auch wirklich entfernen? Oder steht etwas besonderes in deinem alten Startscript /etc/init.d/fhem ?
Hi
Führt das nicht alles eher an der eigentlichen Ursache des Problems vorbei (neben dem "überholten" Buster).
Nämlich die von Beta-User aufgezeigten USB Interfaces und die von Jörg genannten Netzwerk"probleme" bei dem Ferseher, Fritzbox, deConz und MQTT2_fhem_Server meckern.
Gruß Ralf
Ich habs gerade nochmal neu gemacht, alsp quasi die Steps aus #13 wiederholt, jetzt startet fhem automatisch.
Damit bin ich zwar immer noch nicht schlauer warum FHEM nächtens abschmiert, aber zumindest sollte es neu starten.
Ich mache auch regelmäßig mit raspibackup Komplettsicherungen vom System. Allerdings scheue ich gerade noch ein komplettes Neuaufsetzen, da auf der Kiste noch andere Dienste (deConz beispielsweise) laufen und ich die nicht alle neu einrichten will. Kann man Buster nicht auch im laufenden Betrieb auf was Neueres hochziehen das noch supportet wird?
Zitat von: RalfRog am 09 Mai 2025, 14:01:51Nämlich die von Beta-User aufgezeigten USB Interfaces und die von Jörg genannten Netzwerk"probleme" bei dem Ferseher, Fritzbox, deConz und MQTT2_fhem_Server meckern.
Das überflüssige USB Interface habe ich inzwischen entfernt, aber bei den NEtzwerkthemen habe ich noch keine Ahnung wie ich da was einmgrenzen kann, bin aber für Ideen natürlich sehr dankbar...
Zitat von: Otto123 am 09 Mai 2025, 10:05:58Man könnte das mal umstellen https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file) (https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)) aber das ist nicht die Lösung für Dein Problem.
War ja meine Rede :)
Wegen dem Netzwerk: Ganz dumme Idee: Wlan wird bei "Gute Nacht" ausgeschaltet oder so etwas? Nachtschaltung in der Fritzbox oder sowas aktiviert?
Klingt doch irgendwie so als geht das Netzwerk kurz vor Mitternacht auch schlafen.
Zitat von: Jackie am 09 Mai 2025, 14:03:26aber zumindest sollte es neu starten.
nur wenn systemd feststellt fhem läuft nicht...
Zitat von: Jackie am 09 Mai 2025, 14:03:26Kann man Buster nicht auch im laufenden Betrieb auf was Neueres hochziehen das noch supportet wird?
Das ist auch immer ein Glücksspiel, und dein System muss ja sowieso repariert werden. Das geschieht sicher nicht automatisch durch ein release upgrade.
Es gibt hier eigentlich keine Abschaltung von Geräten Nachts, deswegen wundert mich das so. Bin gespannt ob ich morgen was aus den Logs herauslesen kann...
Je nachdem wann du so müde wirst, würde ich heute vor Mitternacht mal schauen ob der Effekt wieder eintritt und dann mal das Netzwerk überprüfen.
Z.B. ob du die Komponenten noch mit den PC erreichst oder ob auf OS-Ebene (RPI) noch ein Ping zu den Komponenten geht.....
Guß Ralf
So, kurzes Update von meiner Seite: nachdem ich alles wie beschrieben umgestellt habe trat kein einziger Absturz / Vorzeitiges Beenden von fhem mehr auf, auch die Logs sind absolut unauffällig. Was auch immer das Verhalten verursacht hat, es ist erst einmal weg. Danke euch allen für eure Hilfe, wenn ich noch etwas herausfinde schreibe ich es hier im Thread.
Dann mal viel Spaß beim Umzug auf die nächste Karte und ein aktuelles OS ;) .
Zitat von: Otto123 am 09 Mai 2025, 14:06:49Klingt doch irgendwie so als geht das Netzwerk kurz vor Mitternacht auch schlafen.
Nach dem Log sogar früher, irgendwann vor 23:30.
LG
pah