FHEM startet nicht - Tipps zur Fehlersuche
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?
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. Das erreicht man z.B. auf folgendem Weg:
- Starte ein Terminalfenster bzw. einen Terminalemulator
- Wechsle in das FHEM-Installationsverzeichnis (meist: /opt/fhem)
cd /opt/fhem
- Erstelle eine Kopie Deiner fhem.cfg, z.B. fhem.cfg.debug
cp fhem.cfg fhem.cfg.debug
- Bearbeite diese Kopie fhem.cfg.debug nun, um die Meldungen in das Terminalfenster zu leiten, in dem der FHEM-Start versucht wird:
nano ./fhem.cfg.debug- In der Zeile mit "attr global logfile" ist der Dateiname durch ein - (Minuszeichen) zu ersetzen. Dadurch werden die FHEM-Ausgaben auf STDOUT (in das Terminalfenster) geschrieben, und FHEM geht nicht in den Hintergrund.
- Starte FHEM im Terminalfenster mit der angepassten Konfigurationsdatei:
perl fhem.pl fhem.cfg.debug- Das Terminalfenster nun nicht schliessen, die Meldungen tauchen hier auf.
- ... Die Fehlermeldungen sind nun zu interpretieren. Gegebenenfalls kann man sie kopieren und als wichtige Information bei einer Hilfeanfrage (z.B. im Forum) verwenden.
- Wenn man genug analysiert hat, FHEM mit Ctrl-C/Strg-C stoppen
Neue Möglichkeit des Debuggen
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 mit ins FHEM Verzeichnis wechseln. Root oder sudo ist nicht erforderlich!
cd /opt/fhem
fhem.cfg - Nutzer:
perl fhem.pl -d fhem.cfg
configDB - Nutzer:
perl fhem.pl -d configDB
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