FHEM nicht erreichbar / Hilfe !

[rasti]

Hallo,

ich kann fhem nicht erreichen.

Mit putty/ssh kann ich mich mit dem Server verbinden und FTP geht auch.
An den logs kann ich sehen, dass fhem weiter werkelt und z.B. Daten loggt.

Wenn ich den fhem Status abfragen will,
kommt eine Fehlermeldung  Failed to get D-Bus connection:

Code Auswählen Erweitern

pi@raspberrypi ~ $ sudo systemctl status fhem
Failed to get D-Bus connection: No connection to service manager.


FHEM läuft :

Code Auswählen Erweitern


pi@raspberrypi ~ $ service fhem status
fhem is running
pi@raspberrypi ~ $ sudo systemctl status fhem
Failed to get D-Bus connection: No connection to service manager.
pi@raspberrypi ~ $ sudo ps aux | grep [f]hem
fhem      1986 41.5  9.8  46088 43920 ?        S    11:59   1:10 perl fhem.pl fhem.cfg
root      1987  0.0  0.2   1716  1228 ?        Ss   11:59   0:00 startpar -f -- fhem
root      2125  0.0  0.2   1780  1152 ?        Ss   11:59   0:00 /bin/sh -c /bin/sleep 300; /usr/bin/touch /opt/fhem/log/fhem.save; /etc/init.d/watchdog start
pi@raspberrypi ~ $

Der Befehl top  zeigt an, dass FHEM das System nicht überlastet.

Keine Updates/Zusatzinstallationen/neue Devices in den letzten Wochen,
der Fehler kam sozusagen aus heiterem Himmel.

Kann hier jemand weiterhelfen ?

Viele Grüße

Ralf

[Christoph Morrison]

Schau mal in /var/log/messages ob es da zum Thema systemd gibt.

[rasti]

Schau mal in /var/log/messages ob es da zum Thema systemd gibt.

Das Unterverzeichnis messages gibt es bei mir nicht:

Code Auswählen Erweitern

pi@raspberrypi /var/log $ ls
alternatives.log       debug.1         faillog         regen_ssh_keys.log
alternatives.log.1     debug.2.gz      fontconfig.log  samba
alternatives.log.2.gz  debug.3.gz      fsck            syslog
alternatives.log.3.gz  debug.4.gz      kern.log        syslog.1
apache2                dmesg           kern.log.1      syslog.2.gz
apt                    dmesg.0         kern.log.2.gz   syslog.3.gz
auth.log               dmesg.1.gz      kern.log.3.gz   syslog.4.gz
auth.log.1             dmesg.2.gz      kern.log.4.gz   syslog.5.gz
auth.log.2.gz          dmesg.3.gz      lastlog         syslog.6.gz
auth.log.3.gz          dmesg.4.gz      lpr.log         syslog.7.gz
auth.log.4.gz          dpkg.log        mail.err        user.log
bootstrap.log          dpkg.log.1      mail.info       user.log.1
btmp                   dpkg.log.10.gz  mail.log        user.log.2.gz
btmp.1                 dpkg.log.2.gz   mail.warn       user.log.3.gz
ConsoleKit             dpkg.log.3.gz   messages        user.log.4.gz
daemon.log             dpkg.log.4.gz   messages.1      watchdog
daemon.log.1           dpkg.log.5.gz   messages.2.gz   wtmp
daemon.log.2.gz        dpkg.log.6.gz   messages.3.gz   wtmp.1
daemon.log.3.gz        dpkg.log.7.gz   messages.4.gz
daemon.log.4.gz        dpkg.log.8.gz   news
debug                  dpkg.log.9.gz   proftpd

Eine Datei mit diesem Namen auch nicht:

Code Auswählen Erweitern

pi@raspberrypi /var $ ls
backups  cache  lib  local  lock  log  mail  opt  run  spool  swap  tmp  www
p

Wo kann/soll ich sonst noch suchen =?

[HeikoBayer]

Aber da ist doch die Datei messages?!?

bootstrap.log          dpkg.log.1      mail.info       user.log.1
btmp                   dpkg.log.10.gz  mail.log        user.log.2.gz
btmp.1                 dpkg.log.2.gz   mail.warn       user.log.3.gz
ConsoleKit             dpkg.log.3.gz   messages        user.log.4.gz
daemon.log             dpkg.log.4.gz   messages.1      watchdog

[rasti]

Aber da ist doch die Datei messages?!?

Oh Mann. Ja sorry ich war blind ....

In dieser Datei kommt das Wort systemd nicht vor !

[frank]

und d-bus auch nicht?

[Christoph Morrison]

Also wenn der d-bus nicht mit dem service manager (systemd) reden kann, dann ist es meist so, dass der systemd irgendein Problem hat und nicht gestartet werden konnte.
Du bist dir ganz sicher, dass du die letzte Zeit nicht irgendwas umkonfiguriert / neu installiert hast? Grep auch mal im Verzeichnis /var/log nach d-bus und systemd.

[rasti]

und d-bus auch nicht?

auch nicht

Also wenn der d-bus nicht mit dem service manager (systemd) reden kann, dann ist es meist so, dass der systemd irgendein Problem hat und nicht gestartet werden konnte.
Du bist dir ganz sicher, dass du die letzte Zeit nicht irgendwas umkonfiguriert / neu installiert hast?

NACHDEM es heute nicht ging habe ich in fhem.cfg den NMAP Netzwerk-Scan rausgeworfen, da dieser mir öfter fhem für ein paar Sekunden blockiert hatte. Hat aber nix gebracht. Ansonsten habe ich in den letzten Tagen (wenn nicht Wochen) sicher nichts neues installiert und eigentlich auch nichts umkonfiguriert.

Grep auch mal im Verzeichnis /var/log nach d-bus und systemd.

Bin absoluter Linuxlaie und musste grep erstmal googeln.
Ich hab sudo grep -irw d-bus /var/log und  sudo grep -irw systemd /var/log
ausgeführt. Ist das richtig so ? Das findet nichts. Nochmaliges Ausführen derselben Befehle
findet dann die grep-Aufrufe in der auth.log aber das ist ja klar....

[HeikoBayer]

Versuch mal sudo ll /var/log | grep d-bus

[rasti]

Versuch mal sudo ll /var/log | grep d-bus

Code Auswählen Erweitern

pi@raspberrypi ~ $ sudo 11 /var/log | grep d-bus
sudo: 11: command not found
pi@raspberrypi ~ $


[HeikoBayer]

Oh, sorry nicht 11 sondern ll --> longlist
Oder aber wenn ll nicht geht, dann ls -l

[rasti]

Oh, sorry nicht 11 sondern ll --> longlist
Oder aber wenn ll nicht geht, dann ls -l

ll ging auch nicht.   Aber ls .  Leider ohne Resultat

Code Auswählen Erweitern


pi@raspberrypi ~ $ ls -l  /var/log | grep d-bus
pi@raspberrypi ~ $ ls -l  /var/log | grep systemd
pi@raspberrypi ~ $

[rasti]

Ich habe heute abend noch etwas Zeit mit meinem fhem Problem verbracht.
Anscheinend ist es nicht so, dass fhem gar nicht mehr erreichbar ist,
aber der Aufbau einer Seite kann schon mal mehrere Minuten dauern oder
das Laden der Seite (egal ob Tablet UI / Apache oder Standard-FHEM-Oberfläche)
bricht halt vorher ab.

Kann es sein, dass D-Bus / systemd gar nichts mit meinem Problem zu tun hat ?
Ich erhalte zwar :

Code Auswählen Erweitern


pi@raspberrypi ~ $ sudo systemctl status fhem
Failed to get D-Bus connection: No connection to service manager.

aber auch

Code Auswählen Erweitern

pi@raspberrypi ~ $ service fhem status
fhem is running
pi@raspberrypi ~ $ sudo /etc/init.d/fhem status
fhem is running


Ich habe was von einem Chrome64-Problem und longpoll/websocket gefunden und mal  testweise von 1 auf websocket umgestellt, ich habe testweise meine 99utils.pm rausgenummen (obwohl schon 2 Jahre alt) aber es ändert sich rein nichts. Updates wurden seit Jahren nicht eingespielt und das letzte einzelne Modul vor 2 Monaten.

Ich habe top laufen lassen und mal einige Minuten zugeschaut. Meist ist die CPU-Auslastung (Raspi 1  ) bei 1-3% Auslastung, jenach dem welcher Prozess gerade oben läuft. Aber : alle paar Minuten belegt FHEM die CPU für 3-10 Sekunden mit Werten bis zu 98%, keine Ahnung ob das so normal ist.

FHEM läuft, Werte über 1-Wire, HMLAN, Tasmota/WLAN, httpmod etc erfasst und im log abgelegt. Die logs kann ich mir per FTP ansehen. Auch schaltet fhem zu den festgelegten Zeiten z-B die Lichter im Wohnzimmer and oder lässt die Jalousien runter. Nur selber schalten kann ich momentan nicht mehr, da ich nicht auf die Oberfläche komme.

Was ist da los ? Bin etwas hilflos....

Schöne Grüße
Ralf

[KölnSolar]

Hallo Ralf,

Was ist da los ?

Auf jeden Fall läuft FHEM noch. 

Aber : alle paar Minuten belegt FHEM die CPU für 3-10 Sekunden mit Werten bis zu 98%

Sieht nach freezes bzw. Blockierung aus. Verdacht: 1-Wire oder httpmod.
Schon mal den Rpi rebootet ? Am besten direkt noch schnell ein image der SD nach dem shutdown.
Grüße Markus

[rasti]

Hallo Ralf,Auf jeden Fall läuft FHEM noch.  8)Sieht nach freezes bzw. Blockierung aus. Verdacht: 1-Wire oder httpmod.
Schon mal den Rpi rebootet ? Am besten direkt noch schnell ein image der SD nach dem shutdown.
Grüße Markus

Hallo Markus,

ja rebootet habe ich mehrmals schon. Das ist ja momentan die einzige Möglichkeit irgendwas zu ändern.
Also fhem.cfg oder *.pm per FTP holen, ändern wieder auf den Raspi und dann per ssh ein sudo reboot 

Und ja ich hatte immer wieder freezes. Und habe noch. Hier die letzten log-Einträge :

Code Auswählen Erweitern

2020.05.12 21:45:02.071 1: 192.168.178.6:1883 reappeared (Mosquitto)
2020.05.12 21:45:02.439 1: Perfmon: possible freeze starting at 21:45:00, delay is 2.438
2020.05.12 21:45:04.875 1: Perfmon: possible freeze starting at 21:45:03, delay is 1.875
2020.05.12 21:45:15.039 1: Perfmon: possible freeze starting at 21:45:05, delay is 10.039
2020.05.12 21:47:23.637 1: 192.168.178.6:1883 disconnected, waiting to reappear (Mosquitto)
2020.05.12 21:47:25.938 1: Perfmon: possible freeze starting at 21:45:16, delay is 129.937
2020.05.12 21:47:27.281 3: Nmap (Netzwerk) - starting network scan
2020.05.12 21:47:31.431 3: ONKYO_AVR device Amplifier is unavailable
2020.05.12 21:47:31.719 3: ONKYO_AVR device Amplifier is available
2020.05.12 21:47:32.167 1: 192.168.178.6:1883 reappeared (Mosquitto)
2020.05.12 21:47:32.746 1: Perfmon: possible freeze starting at 21:47:26, delay is 6.745
2020.05.12 21:47:34.926 1: Perfmon: possible freeze starting at 21:47:33, delay is 1.926
2020.05.12 21:47:43.969 1: Perfmon: possible freeze starting at 21:47:35, delay is 8.969
2020.05.12 21:48:28.262 3: Nmap (Netzwerk) - network scan done
2020.05.12 21:48:28.270 1: Perfmon: possible freeze starting at 21:47:45, delay is 43.27

Ich dachte, die lägen an NMAP und habe die kleinen Verzögerungen (ab und zu dann mal 5-10s) dann so hingenommen.
Aber oben der letzte freeze im log mit 43s ist schon heftig und da ist nmap wohl nicht schuld dran.

Meinst du ich sollte mal vielleicht erstmal alle Devices mit httpmod und wenn das nicht hilft die Onewire-Devices aus der fhem cfg rausnehmen ? Andere Vorschläge ?

Viele Grüße
Ralf