Hallo,
ich habe gerade ein Riesen Problem. Nach einem Reboot des RasPi startet FHEM nicht mehr. Meine gesamte Haussteuerung (Heizung, Klima, PV-Anlage/-Speicher, E-Auto laden/entladen) hängt da dran.
Vorgeschichte:Meine FHEM-Installation ist relativ groß und jetzt wo die Sonne wieder richtig scheint gibt es auch wieder sehr viele Daten/Events von den verschiedenen PV-Wechselrichtern. Dadurch geht die Load zwischen 7-20 Uhr auf nahezu 100%.
Um herauszufinden wer der Hauptverursacher ist habe ich Apptime gestartet.
Nach einer kurzen Laufzeit (paar Minuten) habe ich dann zum Beenden per "sudo reboot" über die Konsole den RasPi neu gestartet.
Problem:Der RasPi hat auch problemlos gestartet, aber FHEM nicht (mit den folgenden Fehlermeldungen).
Zitatfhem.service: Scheduled restart job, restart counter is at 160
Stopped fhem.service - FHEM Home Automation
fhem.service: Start request repeated too quickly
fhem.service: Failed with result 'exit-code'
Failed to start fhem.service - FHEM Home Automation
Nach einigem Suchen bin ich auf die Einstellung "RestartSec" in der systemd aufmerksam geworden und habe die Zeile "RestartSec=5" zusätzlich eingefügt (hatte auch 2 und 10s versucht). Aber auch damit startete FHEM nicht. Die Meldungen die ich jetzt erhalte lauten:
Zitat$ sudo systemctl start fhem
Job for fhem.service failed because the control process exited with error code.
See "systemctl status fhem.service" and "journalctl -xeu fhem.service" for details.
pi@raspberrypi:~ $ service fhem status
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; preset: enabled)
Active: activating (start) since Wed 2025-04-02 20:40:56 CEST; 31ms ago
Cntrl PID: 4395 (perl)
Tasks: 1 (limit: 4443)
CPU: 27ms
CGroup: /system.slice/fhem.service
└─4395 /usr/bin/perl fhem.pl fhem.cfg
$ sudo systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Wed 2025-04-02 20:43:18 CEST; 1s ago
Process: 4461 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=13)
CPU: 113ms
Ich habe gerade keine Idee mehr was ich tun könnte.
Ich hoffe Jemand hat ein paar Tips für mich.
Zuerst einen Blick ins Logfile werfen, vielleicht finden sich da schon Hinweise.
Falls nicht, greift das übliche und schon tausend Mal beschriebene Standardvorgehen:
Den FHEM Service beenden und FHEM auf der Systemconsole von Hand starten, ggf. im debug Modus.
Dann sollte sich herausfinden lassen, warum FHEM nicht startet.
Im Logfile steht leider nichts. Der letzte Eintrag ist "Server shutdown". Davor sind nur die Einträge von Apptime.
Was meinst Du mit "Den FHEM Service beenden"? Der läuft doch gar nicht. Starten von FHEM über die Konsole habe ich schon mehrfach versucht. Das gibt ja die oben beschriebenen Fehlermeldungen.
Wie geht das mit dem Debug-Modus? Da habe ich leider keine Ahnung.
Debug Modus ist hier beschrieben https://fhem.de/commandref_DE.html#intro
ZitatFalls FHEM mit der -d Koommandozeilenoption gestartet wurde (perl fhem.pl -d fhem.cfg), dann wird verbose auf 5 gesetzt und die Logs werden auf STDOUT geschrieben.
So, ich hab mal den Debug-Modus gestartet. Damit läuft FHEM tatsächlich. Auch FHEM-Web funktioniert damit. Aber was ich nun in den durchrasenden Daten "analysieren" soll/könnte verstehe ich nicht, zumal ich nach dem Abbruch auch nur einen Teil der Daten anschauen kann. Ich wüßte auch nicht wonach ich suchen sollte.
Hallo Otto,
ah ok. D.h. ich lasse FHEM im Debug-Modus eine Weile laufen und schaue dann im Log-File nach. Aber wonach muß ich denn suchen was mir den regulären Start verhindert?
OK, ich glaube ich habe das mißverstanden. Im Logfile steht nichts Neues nach dem Debug-Start. Wo und nach was muß ich denn suchen?
Naja die Erwartung wäre gewesen, dass FHEM auch im Debug Modus nicht startet, dann hätte man ev. gesehen was er zuletzt gemacht hat.
Wie hast Du denn den Wert in die Datei fhem.service geschrieben? Also mit welchem Tool?
über die Konsole mit dem MultiCommander (also NortonCommander-Clon) mit dem eingebauten Editor (F4). Nach der Änderung habe ich, wie in der Meldung der Konsole gefordert, "systemctl daemon-reload" ausgeführt.
Im Debug-Modus ist FHEM ohne Probleme gestartet und läuft offensichtlich "normal". Dann sollte es doch kein Riesen-Problem sein, oder? Ich weiß halt nur nicht wo ich suchen soll.
Kannst Du mal ins journal schauen?
journalctl -b -u fhem.service
Fehler 13 klingt für mich nach Zugriffsrechten, ich kann aber falsch liegen.
Ich vermute Du hast die Unitdatei fhem.service irgendwie verhunzt ;)
Tipp: in Zukunft besser
sudo systemctl edit --full fhem
Ah mist, jetzt war Otto schneller:D
Aufschluss darüber, wieso FHEM nicht startet, gibt diese Zeile, vor allem das "code=exited, status=13"
Zitat von: Guzzi-Charlie am 02 April 2025, 20:48:36Process: 4461 ExecStart=/usr/bin/perl fhem.pl (https://fhem.pl/) fhem.cfg (code=exited, status=13)
Von dem was man über Google so findet bedeutet status 13 irgendein permission-Problem.
Für FHEM findet man dieses Thema hier (https://forum.fhem.de/index.php?topic=132391.0), wo auch jemand ein status=13-Problem hatte
Lag damals wohl auch an falschen permissions: https://forum.fhem.de/index.php?topic=132391.msg1265502#msg1265502
Im Zweifel mal schauen, ob das bei dir alles passt/du da aus Versehen irgendwas geändert hast und ggfs. anpassen (https://forum.fhem.de/index.php?topic=132391.msg1265540#msg1265540).
Wieso das dann aber im debug mode doch startet, keine Ahnung?
ZitatStarting fhem.service - FHEM Home Automation...
Apr 02 20:18:05 raspberrypi perl[3662]: Can't open /opt/fhem/log/fhem-2025-04.log: Permission denied at fhem.pl line 2945.
fhem.service: Control process exited, code=exited, status=13/n/a
fhem.service: Failed with result 'exit-code'.
Failed to start fhem.service - FHEM Home Automation.
Da zeigt er tatsächlich für das Logfile ein " Permission denied" an. Das Logfile hatte ich tatsächlich vor dem reboot umbenannt. Ist das etwa das Problem?
Zitat von: Guzzi-Charlie am 02 April 2025, 22:12:45Ist das etwa das Problem?
Ja, wenn Du die Rechte versaut hast und der user fhem kein Schreibrecht mehr am Logfile hat, bzw. kein Logfile mehr da ist (hab ich nie getestet)
Kommt halt drauf an, mit welchem Tool du das umbenannt hast. mv ändert (auf dem gleichen Laufwerk) normalerweise keine permissions, aber andere Tools vielleicht schon.
Aber jetzt kannst du ja das Logfile einfach mit den richtigen Permissions ausstatten und dann beim nächsten Umbenennen mal vor und nach dem Umbenennen die Ausgabe von ls -la vergleichen.
Vielleicht noch der Hinweis, dass ein Umbenennen (halb-)automatisch verwalteter Logfiles je nach dem nicht die beste Idee ist bzw. gut durchdacht sein sollte ...
Ich hab nur die Datei umbenannt. Wie bekomme ich das jetzt wieder in Ordnung? Der Punkt ist ja, das FHEM vor dem Reboot noch problemlos in die Datei geschrieben hat.
eigentlich legt FHEM einfach eine neue an - gerade getestet. Da hast Du noch was anderes gemacht.
Wenn man
attr global logfile ./log/fhem-%Y-%m.log neu setzt wird auch eine neue Datei erzeugt wenn sie nicht existiert - auch getestet.
Eigentlich aber bei mir offensichtlich nicht. Ich habe mir gerade die Rechte aller Log-Dateien angeschaut. Die stehen alle auf fhem dialout, NUR die fhem.log steht auf pi pi.
existiert denn ein Logfile?
ls -lha /opt/fhem/log/fhem-2025-04.log
ja.
Wie kann ich diesem File denn jetzt die richtigen Rechte geben?
und mit dem stimmt alles?
Steht da was drin oder ist der leer?
Steht im journal immer noch das gleiche nach dem erfolglosen Start?
Im Journal steht immer noch das Gleiche. Das Logfile scheint in Ordnung und ist gefüllt. Nur als Rechte wird pi pi angezeigt.
von was redest Du? vom /opt/fhem/log/fhem-2025-04.log oder von fhem.log (deine Aussage in #15) ?
Wenn die Rechte nicht fhem:dialout sind, sind sie falsch! Sagt ja der Fehler!?
Entschuldigung, das war ein Tippfehler. Es geht um die fhem-2025-04.log. Und Ja, Du hast Recht. Die Rechte sind falsch, hab ich ja schon geschrieben.
Aber lange Rede kurzer Sinn: Es läuft glaube ich wieder. Habe die Rechte auf fhem:dialout geändert und dann ließ sich FHEM wieder starten. Ich muß nun mal prüfen ob wirklich alles wieder funktioniert.
Vielen, vielen Dank erstmal für die Unterstützung!