FHEM startet nicht - Tipps zur Fehlersuche: Unterschied zwischen den Versionen

Aktuelle Version vom 8. Februar 2024, 14:58 Uhr

Es gibt einen weiteren Artikel zur Fehlersuche. Hilfe! Mein FHEM funktioniert nicht!

Kein Zugriff auf FHEMWEB/FHEM startet nicht - Was kann ich tun?

Deine FHEMWEB-Seite ist nicht erreichbar? Ist FHEM tot, oder ist das Netzwerk kaputt? Was kann ich machen, um zu prüfen, woran es genau liegt?

In diesem Wiki-Artikel soll es darum gehen, wie Du für Dich prüfen kannst, ob ein Fehler bei FHEM, im Netzwerk oder ein anderes Problem vorliegt.

Prüfen: Läuft überhaupt ein FHEM-Prozess?

Man kann sich unter einem Linuxsystem sämtliche laufende Prozesse auflisten lassen

ps ax

Der Befehl ps listet je nach Argument alle laufende Prozesse auf. Die Liste kann man nun noch nach einem bestimmten Prozess filtern. Aufruf und Ausgabe einer Prozessliste mit einem Filter nach perl sieht z. B. so aus:

ps ax | grep perl

cooltux@fhem01-cluster:~> ps ax | grep perl

11320 pts/0 S+ 0:00 grep --color=auto perl

Wie wir sehen, wird hier lediglich der gerade ausgeführte Befehl ps gefunden (weil das Wort perl in der Aufrufzeile stand. Es wird hier überhaupt kein Perl-Prozess gelistet. Aktuell läuft also definitiv kein FHEM, das ja ein Perl-Programm/Prozess ist.

Eine Prozessliste mit einem laufenden FHEM-Prozess könnte so aussehen:

[11:31 root@fhem01-cluster cooltux] > ps ax | grep perl

15852 ? R 2119:09 /usr/bin/perl fhem.pl configDB

21447 pts/0 S+ 0:00 grep perl

FHEM (perl fhem.pl ...) ist in diesem Fall also aktiv.

systemd

Nutzt das Linux-System den systemd, kann mit folgendem Befehl der Status des FHEM-Prozesses geprüft werden:

service fhem status

Eine Ausgabe könnte z.B. so aussehen:

 ● fhem.service - FHEM Home Automation
   Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2018-08-09 14:32:16 CEST; 20h ago
  Process: 27641 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=0/SUCCESS)
 Main PID: 27643 (perl)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/fhem.service
           └─27643 /usr/bin/perl fhem.pl fhem.cfg
 
 Aug 09 14:32:16 fhem-host systemd[1]: Starting FHEM Home Automation...
 Aug 09 14:32:16 fhem-host systemd[1]: Started FHEM Home Automation.

Prüfen: Ist der laufende FHEM-Prozess überlastet?

Ich sollte mir anschauen, ob der FHEM-Prozess vielleicht zu sehr ausgelastet ist, der Prozess also 100 Prozent CPU Auslastung produziert?

Ein weiterer Linuxbefehl top wird uns hierbei behilflich sein:

 [11:38 root@fhem01-cluster cooltux] > top
 top - 11:38:18 up 11 days, 18:58,  1 user,  load average: 1,07, 1,03, 1,00
 Tasks: 125 total,   2 running, 123 sleeping,   0 stopped,   0 zombie
 %Cpu(s): 24,9 us,  0,9 sy,  0,0 ni, 74,1 id,  0,0 wa,  0,0 hi,  0,1 si,  0,0 st
 KiB Mem:    945524 total,   833532 used,   111992 free,    41552 buffers
 KiB Swap:   102396 total,    46564 used,    55832 free.   496240 cached Mem
 PID   USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 15852 fhem      20   0  103652  82160   5068 R 100,0  8,7   2125:41 perl                                                                                                               
 21683 root      20   0    5740   2560   2092 R   1,0  0,3   0:00.37 top                                                                                                                
 19129 cooltux   20   0   86204  22348   3668 S   0,3  2,4  64:16.90 insync-portable                                                                                                    
 21350 cooltux   20   0   11436   2848   2248 S   0,3  0,3   0:00.10 sshd                                                                                                               
     1 root      20   0   23292   2368   1380 S   0,0  0,3   0:54.23 systemd                                                                                                            
     2 root      20   0       0      0      0 S   0,0  0,0   0:01.09 kthreadd                                                                                                           
     3 root      20   0       0      0      0 S   0,0  0,0   3:37.20 ksoftirqd/0                                                                                                        
     5 root       0 -20       0      0      0 S   0,0  0,0   0:00.00 kworker/0:0H                                                                                                       
     7 root      20   0       0      0      0 S   0,0  0,0   8:20.71 rcu_sched                                                                                                          
     8 root      20   0       0      0      0 S   0,0  0,0   0:00.00 rcu_bh                                                                                                             
     9 root      rt   0       0      0      0 S   0,0  0,0   0:05.45 migration/0

Hier können wir nun eindeutig erkennen, dass unser FHEM die CPU mit 100 Prozent auslastet. FHEM hat also ein Problem!

Zum Vergleich ein FHEM/Perl-Prozess ohne Probleme:

 [11:50 root@fhem01-cluster cooltux] > top
 top - 11:50:33 up 11 days, 19:10,  1 user,  load average: 0,84, 1,03, 1,00
 Tasks: 133 total,   1 running, 132 sleeping,   0 stopped,   0 zombie
 %Cpu(s):  0,6 us,  0,8 sy,  0,0 ni, 98,6 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
 KiB Mem:    945524 total,   818344 used,   127180 free,    43748 buffers
 KiB Swap:   102396 total,    46820 used,    55576 free.   489652 cached Mem
   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 22074 fhem      20   0   86424  68516   7200 S   1,3  7,2   0:47.64 perl
 22294 root      20   0    5740   2564   2092 R   1,3  0,3   0:00.19 top
 22296 fhem      20   0   86424  63556   2240 S   1,3  6,7   0:00.04 perl
 22297 fhem      20   0    2088    408    328 S   0,7  0,0   0:00.02 ping
     7 root      20   0       0      0      0 S   0,3  0,0   8:21.23 rcu_sched
  1366 mysql     20   0  620608 157132   5736 S   0,3 16,6  70:12.59 mysqld
 19481 root      20   0       0      0      0 S   0,3  0,0   0:02.35 kworker/3:0
     1 root      20   0   23292   2408   1420 S   0,0  0,3   0:54.27 systemd
     2 root      20   0       0      0      0 S   0,0  0,0   0:01.09 kthreadd
     3 root      20   0       0      0      0 S   0,0  0,0   3:37.42 ksoftirqd/0
     5 root       0 -20       0      0      0 S   0,0  0,0   0:00.00 kworker/0:0H

Prüfen: Stimmen die Dateiberechtigungen?

Alle Dateien im Verzeichnis /opt/fhem/ und allen Unterverzeichnissen gehören nach der Installation dem Benutzer fhem und der Gruppe dialout. Man kann es leicht prüfen: ls -la /opt/fhem/

Häufig wird der Eigentümer durch Manipulation der Dateien falsch gesetzt, mit diesem Befehl kann man alle Dateien auf den Eigentümer fhem und dessen primäre Gruppe setzen.

sudo chown -R fhem: /opt/fhem/

Die Setup Routine setzt den Besitz auf fhem:dialout sudo chown -R fhem:dialout /opt/fhem/

Und wenn sich gar nichts mehr tut?

Die letzen Zeilen im existierenden FHEM Log anzeigen

So lässt man sich auf Systemebene die letzen 20 Zeilen im Log anzeigen

tail -n 20 /opt/fhem/log/fhem-$(date '+%Y-%m').log

Fehlernachrichten von FHEM bei dessen Start analysieren

In der Regel werden die Ausgaben von FHEM, auch die beim Start, gemeinsam mit vielen anderen Nachrichten in ein Logfile geschrieben. Dort kann natürlich nach Ursachen geforscht werden.

Eine einfachere Auswertung wird möglich, wenn man diese Meldungen zeitweilig in einem Terminalfenster (das Ding, um Kommandozeilenbefehle einzugeben) angezeigt bekommt.

Seit dem 01.08.2017 gibt es die Möglichkeit beim manuellen Starten von FHEM im Terminal den Schalter -d zu verwenden (Beitrag). Dieser startet FHEM mit den beiden gesetzten Attributen attr global logfile - und attr global verbose 5 und gibt somit alle Meldungen im Terminalfenster aus. Zuerst ins FHEM Verzeichnis wechseln. Root oder sudo ist nicht erforderlich!

Allerdings muss ein (mit 100 %) laufendes FHEM zunächst beendet werden! z.B.: sudo systemctl stop fhem

ins FHEM Verzeichnis wechseln: cd /opt/fhem

Je nach Konfiguration FHEM im debug Modus starten:

fhem.cfg - Nutzer: perl fhem.pl -d fhem.cfg

configDB - Nutzer: perl fhem.pl -d configDB

Wenn man genug analysiert hat, FHEM mit Ctrl-C/Strg-C stoppen

Es ist nach dem letzten Update passiert?

Beispielhaft für das Vorgehen wird das in diesem Forumthread beschrieben. FHEM speichert vor dem Update die Dateien ins Verzeichnis restoreDir die aktualisiert werden. Es handelt sich dabei nicht um eine komplette Sicherung des Systems!

Man kann sich über die gesicherten Versionen/Dateien einen Überblick verschaffen (Datum anpassen!):

ls -lha /opt/fhem/restoreDir/update

ls -lhaR /opt/fhem/restoreDir/update/2020-02-28

Hat man die verursachende Datei ermittelt, kann man gezielt diese Datei wieder herstellen:

sudo -su fhem cp /opt/fhem/restoreDir/update/2021-02-06/FHEM/NameDerDatei /opt/fhem/FHEM/

Es gibt bei einigen Modulen Abhängigkeiten von anderen Dateien, es ist dringend angeraten, dann den kompletten zusammengehörigen Satz wieder herzustellen!

Will man einen kompletten Schritt zurück vor dem Update gehen, weil man den Fehler nicht einkreisen kann, stellt man so alles vor dem Update wieder her.

sudo -su fhem cp -R /opt/fhem/restoreDir/update/2021-02-05/* /opt/fhem/

Die config Datei ist das Problem?

Bei jedem save wird in /opt/fhem/restoreDirs eine Sicherung der fhem.cfg und das Statefile fhem.save durchgeführt.

Auf der Kommandozeile vom System kann man sich einen Überblick verschaffen:

ls -lha /opt/fhem/restoreDir/save

Dort sollten Pfade mit Datums Angaben sein.

Den exakten Zeitpunkt der gesicherten Dateien kann man sich so anzeigen lassen (Beispiel).

ls -lhaR /opt/fhem/restoreDir/save/2020-02-28

Die "lastKnownGood" Konfiguration kann man so wiederherstellen und anschließend FHEM wieder starten:

sudo -su fhem cp -R /opt/fhem/restoreDir/save/2020-02-28/* /opt/fhem/

Die Berechtigungen werden durch verwenden von User fhem eigentlich erhalten.

Falls die Berechtigungen nicht stimmen:

sudo chown fhem: /opt/fhem/fhem.cfg

sudo chown fhem: /opt/fhem/log/fhem.save

Minimal Config starten

Wenn gar nichts mehr geht, ist es manchmal ratsam eine minimal Konfiguration zu starten um die Hardware oder Netzwerkanbindung an sich zu testen.

Wichtig ist zunächst sicher zu stellen, dass kein FHEM Prozess läuft (siehe oben)

Die fhem.cfg.demo (Bestandteil von FHEM) ist extra für den interaktiven Start gedacht, die Logausgaben landen in der Konsole.

Die Demo kann interaktiv mit Ctrl+C beendet werden.

cd /opt/fhem
sudo perl fhem.pl fhem.cfg.demo

Oder man holt sich die Original minimal fhem.cfg

cd /opt/fhem
sudo -su fhem wget -qO minimal.cfg https://svn.fhem.de/fhem/trunk/fhem/fhem.cfg
sudo perl fhem.pl minimal.cfg

Damit wäre es auch möglich ein Update zu machen oder Dateien wie im Update Wiki Artikel beschrieben direkt aus dem SVN zu holen.

Hinweis: Es ist wichtig fhem.pl mit erhöhten Rechten zu starten, da sonst fhem.pl nicht auf den user fhem umschalten kann - das würde zu Rechte Problemen führen!

Für configDB User gibt es den rescue Modus.

Ist die Platte voll?

So kann man anzeigen, wieviel Platz frei / belegt ist:

df -h

Ist 100% belegt oder 0 verfügbar, dann kann man suchen, wo die "großen Brocken" sind:

sudo du -h -d 2 / |sort -h|tail

Ist der FHEM Pfad das Problem, kann man gezielter suchen:

du -h /opt/fhem/backup

du -h /opt/fhem/log

Und eventuell löschen, im Beispiel die ältesten fünf Backups Schritt für Schritt:

alle anzeigen,
die ältesten 5 anzeigen,
die ältesten 5 löschen.

ls -lha /opt/fhem/backup/ 
ls -d /opt/fhem/backup/FHEM-*.tar.gz |head -5
ls -d /opt/fhem/backup/FHEM-*.tar.gz |head -5|xargs rm