FHEM nicht erreichbar / Hilfe !

Christoph Morrison · 12 Mai 2020, 22:15:55

Zitat von: rasti am 12 Mai 2020, 21:56:51
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 ?

Du könntest die HTTPMOD-Devices auch erstmal deaktivieren, die brauchst du nicht rausnehmen. Bei 1-Wire weiß ich nicht, ob man die deaktivieren kann.
CPU Usage ist bei einem System auch nicht die einzige Metrik die klemmen kann und es ist auch nicht so, dass die CPU-Usage automatisch mit hoch geht. Guck auch mal in Richtung I/O auf die Karte (SD-Karte ist meistens eine schlechte Idee). NMAP würde ich auch mal testweise deaktivieren, falls du das noch nicht gemacht hast.

Otto123 · 12 Mai 2020, 23:50:05

Hi,

wenn es wirklich der "heitere Himmel" war - dann gibt es beim raspberry meist zwei Gründe:
- SD Card defekt
- Netzteil defekt / schlecht

Ich würde also erstmal ein offline Image der SD Card machen. (Und eventuell dieses Image auf einer neuen SD Card versuchen zu starten)

Lässt sich der fhem Service ordentlich beenden?
Läuft die demo.cfg?

Netzwerkkabel mal getauscht?

Gruß Otto

rasti · 13 Mai 2020, 02:09:08

Hallo Otto,

Zitat von: Otto123 am 12 Mai 2020, 23:50:05
wenn es wirklich der "heitere Himmel" war - dann gibt es beim raspberry meist zwei Gründe:
- SD Card defekt
- Netzteil defekt / schlecht

Ich würde also erstmal ein offline Image der SD Card machen. (Und eventuell dieses Image auf einer neuen SD Card versuchen zu starten)

Ich hatte beides schonmal - aber da ging dann rein gar nix mehr. Dass sonst alles mit dem Raspi läuft (ssh, ftp, apacheserver) aber FHEM Ausfälle und Freezes zeigt ist schon merkwürdig. Naja, werde ich wahrscheinlich mal versuchen - ich weiss ja sonst nicht was ich noch machen könnte....

Zitat
Lässt sich der fhem Service ordentlich beenden?

Was heisst ordentlich? Ich kann fhem manuell anhalten, Status sagt dann not running - und manuell´starten, dann kommt Status running. Ist es das was du "ordentlich" nennst ?

Zitat
Läuft die demo.cfg?

Ja läuft eigentlich flüssig. Aber auch hier kommen perlmon freezes, siehe unten der ssh-Mitschnitt .

Zitat
Netzwerkkabel mal getauscht?

Vor dem Fehler - nein
nach dem Fehler : auch nicht aber ich hatte probeweise alle Kabel mal ab und wieder dran, auch LAN routerseitig.

VIele Grüße

Ralf

Code Auswählen

pi@raspberrypi ~ $ sudo /etc/init.d/fhem stop
Stopping fhem...
pi@raspberrypi ~ $ service fhem status
fhem is not running
pi@raspberrypi ~ $ cd /opt/fhem
pi@raspberrypi /opt/fhem $ perl fhem.pl fhem.cfg.demo
2020.05.13 01:54:21 2: Perfmon: ready to watch out for delays greater than one s                                                                                        econd
2020.05.13 01:54:21 1: Including fhem.cfg.demo
2020.05.13 01:54:22.001 3: telnetPort: port 7072 opened
2020.05.13 01:54:22.857 3: WEB: port 8083 opened
2020.05.13 01:54:22.875 3: WEBphone: port 8084 opened
2020.05.13 01:54:22.892 3: WEBtablet: port 8085 opened
2020.05.13 01:54:23.165 1: define Logfile FileLog ./log/fhem-%Y-%m.log fakelog:                                                                                         Can't open ./log/fhem-2020-05.log: Permission denied
2020.05.13 01:54:23.377 2: eventTypes: loaded 109 events from demolog/eventTypes                                                                                        .txt
2020.05.13 01:54:23.622 1: CUL_0 device is none, commands will be echoed only
2020.05.13 01:54:27.348 1: Including ./demolog/fhem.save
2020.05.13 01:54:27.758 1: configfile: Can't open ./log/fhem-2020-05.log: Permis                                                                                        sion denied
Cannot load module RSS
statefile: Please define Logfile first

2020.05.13 01:54:27.893 2: Messages collected while initializing FHEM: configfil                                                                                        e: Can't open ./log/fhem-2020-05.log: Permission denied Cannot load module RSS s                                                                                        tatefile: Please define Logfile first
2020.05.13 01:54:27.896 0: Featurelevel: 5.7
2020.05.13 01:54:27.899 0: Server started with 56 defined entities (fhem.pl:1133                                                                                        8/2016-04-28 perl:5.014002 os:linux user:pi pid:2445)
2020.05.13 01:54:27.902 1: Perfmon: possible freeze starting at 01:54:22, delay                                                                                         is 5.902
2020.05.13 01:54:52.671 1: Perfmon: possible freeze starting at 01:54:47, delay                                                                                         is 5.67
2020.05.13 01:55:04.931 1: Perfmon: possible freeze starting at 01:54:59, delay                                                                                         is 5.931
2020.05.13 01:55:13.689 3: FS20 set Alarm off
2020.05.13 01:55:26.942 1: Perfmon: possible freeze starting at 01:55:21, delay                                                                                         is 5.942

rasti · 13 Mai 2020, 02:20:27

Zitat von: Christoph Morrison am 12 Mai 2020, 22:15:55
Du könntest die HTTPMOD-Devices auch erstmal deaktivieren, die brauchst du nicht rausnehmen. Bei 1-Wire weiß ich nicht, ob man die deaktivieren kann.
CPU Usage ist bei einem System auch nicht die einzige Metrik die klemmen kann und es ist auch nicht so, dass die CPU-Usage automatisch mit hoch geht. Guck auch mal in Richtung I/O auf die Karte (SD-Karte ist meistens eine schlechte Idee). NMAP würde ich auch mal testweise deaktivieren, falls du das noch nicht gemacht hast.

Ich habe nun nacheinander
* httpmod-Devices und Prolanta
* 1Wire-Devices
* Homematic-Devices
* MQTT-Devices (mosquitto läuft auf selben Raspi)
aus der fhem-cfg rausgenommen und jedesmal danach rebootet.

Leider keine Änderungen - alles immer seehr langsam, eigentlich kein Zugriff möglich
und immer laaange Freezes (60-100s) in fhem.log zu finden.

Bin auch die alten logs durchgegangen - bevor der Fehler auftrat, hatte ich nur vereinzelte kurze
Freezes (1-10s) und bei einem nmap jeweils ein langes (ca. 40s). Jetzt seit der Fehler auftritt, stehen auch
besagte lange Freezes im log. Und in diesen letzten 1-2 Tagen habe ich auch rein gar nichts geändert sprich
keine Änderung an der fhem.cfg oder irgendwelchen Modulem vorgenommen.
Das würde für die SD-Kartentheorie sprechen....

KölnSolar · 13 Mai 2020, 06:49:42

ZitatDas würde für die SD-Kartentheorie sprechen....

Immer denkbar bei Problemen, die plötzlich und ohne jegliche vorherige Änderung des Systems auftreten. Allerdings kann ich mich nicht an Problemfälle erinnern, wo die defekte SD "nur" zu freezes führte. $:-\$
Sicherlich ist es aber bei massiven Problemen immer der beste Weg, ein funktionsfähiges image auf neuer SD laufen zu lassen, um die SmartHome-Funktionalität wieder zu haben und daher ungestresst dem Fehler auf die Spur zu kommen.

Bei den 5s-freezes kommt mir global dnsServer in den Sinn. Hast Du den gesetzt ? Vielleicht ist ja im Netzwerk was allgemeines im argen(Otto spekulierte ja auch schon in die Richtung).

Für die freeze-Prävention und -monitoring nutze ich freezemon anstatt perfmon. Das liefert "Verdächtige" und es wird ein zusätzliches freeze-Log erstellt, wo die Aktionen vor u. nach dem freeze mit global verbose=5 gelogged werden.

Grüße Markus

Otto123 · 13 Mai 2020, 08:58:14

Zitat von: rasti am 13 Mai 2020, 02:09:08
Ist es das was du "ordentlich" nennst ?

Ja das meinte ich.

frank · 13 Mai 2020, 09:42:11

Code Auswählen

2020.05.13 01:54:27.758 1: configfile: Can't open ./log/fhem-2020-05.log: Permis
ich denke, das soll "permission denied" sein.

wie sind die berechtigungen?
gibt es eventuell ein grosses "durcheinander" im fhem bereich?

zeig mal den inhalt vom log ordner mit "ls -al".

Otto123 · 13 Mai 2020, 09:48:04

@Frank Das ist das log aus dem Start der demo.cfg . Wenn man diesen Start als User pi macht, schaltet fhem.pl nicht um auf User fhem und hat damit keinen Zugriff auf das schon existierende Log von dem Standarddienst.

frank · 13 Mai 2020, 10:55:45

ok, macht sinn.

berechtigungen würde ich trotzdem checken.
diese freezes, sowohl in demo.cfg, als auch fhem.cfg, sind schon extrem.

Christoph Morrison · 13 Mai 2020, 10:56:16

Zitat
Code Auswählen Erweitern
Cannot load module RSS statefile: Please define Logfile first

Ich bin mir gerade nicht sicher (und ich hab nix gefunden, als ich in der SVN-Version der fhem.cfg-demo nachgeschaut habe), aber RSS wird dort nicht geladen. Weshalb wird dann versucht RSS zu laden und warum hast du RSS nicht? Die ist ja etwas älter.

Code Auswählen

$ svn info 02_RSS.pm
Path: 02_RSS.pm
Name: 02_RSS.pm
Working Copy Root Path: /Volumes/Development/hab/core/subversion
URL: svn+ssh://svn.fhem.de/trunk/fhem/FHEM/02_RSS.pm
Relative URL: ^/trunk/fhem/FHEM/02_RSS.pm
Repository Root: svn+ssh://svn.fhem.de
Repository UUID: 2b470e98-0d58-463d-a4d8-8e2adae1ed80
Revision: 21919
Node Kind: file
Schedule: normal
Last Changed Author: neubert
Last Changed Rev: 16812
Last Changed Date: 2018-06-03 21:52:27 +0200 (Sun, 03 Jun 2018)
Text Last Updated: 2020-04-15 08:45:34 +0200 (Wed, 15 Apr 2020)
Checksum: 8c0935c9b8eaa41621c4aad2c38904605c83e8a9

rasti · 13 Mai 2020, 14:44:48

Hallo zusammen,

kurzes Update nach einem laaangen Vormittag mit FHEM.
- aktuelles Image auf neuer SD-Karte => ging nicht
- aktuelles Image auf neuer/alter SD-Karte in anderem Raspi1 => ging nicht
- altes Image aus 2018 auf alter SD-Karte im Original.´-Raspi1 => ging nicht
- hatte nebenbei bemerkt, dass der Raspi zeitweise keinen Netzzugang hatte,
d.h. aus irgendeinem Grund schlug z.B. wget fehl
- daraufhin Fritzbox angeschaut und das gefunden :

Code Auswählen

12.05.20	16:58:11	Anmeldung des Benutzers nas an der FRITZ!Box Benutzeroberfläche von IP-Adresse 195.154.63.224 gescheitert (falsches Kennwort).
12.05.20	16:35:20	Anmeldung des Benutzers nil an der FRITZ!Box Benutzeroberfläche von IP-Adresse 77.247.108.15 gescheitert (falsches Kennwort).
=> https://www.abuseipdb.com/check/77.247.108.15
=> https://www.abuseipdb.com/check/195.154.63.224

- Fritzbox rebootet
- LAN-Stecker in anderen Bridgeeingang => ging nicht
- Wieder Image aus 2020 auf alter SD-Karte im Original.´-Raspi1 => ging nicht

Ich hab mich dann seelisch und moralisch schon drauf eingestellt, alles neu aufzusetzen,
das schieb ich sowieso schon laange vor mir her und
einen Raspi3 hätte ich gerade übrig .... habe dann alles wieder WIE ES WAR ins Original-Gehäuse
gepackt, nochmal eingeschaltet und die Kiste => geht !!!

Ich habe keine Ahnung woran es gelegen hat aber es läuft wieder.
Richtig flott, man könnte (wenn man nicht gerade viele Plots auf einer Seite hat)
denken ich hätte schon auf Raspi 3 oder upgegradet :

Die logs haben noch manchmal kurze Freezes aber meistens nur 2-3 Sekunden.
Selbst nmap (30-40 hostsUp hat vorher 40sek gebraucht ) ist in 6 Sekunden fertig und blockiert nicht mehr wirklich

Code Auswählen

2020.05.13 14:05:24.509 3: Nmap (Netzwerk) - starting network scan
2020.05.13 14:05:30.373 3: Nmap (Netzwerk) - network scan done

Ich finde momentan noch im log :

Code Auswählen

2020.05.13 13:54:46.181 1: PERL WARNING: Scalar value @fld[5] better written as $fld[5] at (eval 627) line 1, <GEN281> line 136.
2020.05.13 13:54:46.182 3: eval: @fld[5]/1000

(mit verschiedenen Werten zu Lines und eval

Code Auswählen

2020.05.13 13:54:22.942 1: PERL WARNING: Argument "0%" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 1256.
2020.05.13 13:54:22.944 1: PERL WARNING: Argument "100%" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 1256.

Code Auswählen

2020.05.13 13:51:33.533 3: IOTA: Read callback: request type was update retry 0, no headers, body empty, 
Error: read from to http://www.coinkurs.com:80 timed out

Code Auswählen


2020.05.13 13:50:28.963 1: statefile: Usage: setstate <name> <state>
where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.

Usage: setstate <name> <state>
where <name> is a single device name, a list separated by komma (,) or a regexp. See the devspec section in the commandref.html for details.

Also es läuft wieder aber ich habe keinen Plan woran das nun gelegen hat.

Bin erstmal wieder froh

KölnSolar · 13 Mai 2020, 14:58:56

Zitatnach einem laaangen Vormittag mit FHEM

Und die vorangegangene Nacht war ja schon kurz.

Aber prima, dass es wieder geht. Jetzt aber schnell noch ein image erstellen....

Klingt dann ja irgendwie nach Netzwerkproblem(Ursache "verwirrte" FritzBox $:-\$ ). Deshalb solltest Du meinen Hinweis zu global dnsServer umsetzen, denn dadurch verhinderst Du blockierendes Verhalten bei Netzwerkzugriffen.
Und freezemon anstatt perfmon einzusetzen wäre auch nicht verkehrt, denn dann sollte der Verursacher von freezes angezeigt werden, wodurch sich auf Netzwerkprobleme schließen ließe.

Otto123 · 13 Mai 2020, 15:35:42

Naja wenn es nicht die SD Card war und auch nicht das Netzteil (Stecker/Kabel?) - äußert sich beides eigentlich massiver $:-\$

Dann tippe ich ich auch nach wie vor auf "Netzwerkkabel" - symbolisch gemeint

und unterschreibe alle Ideen von Markus

rasti · 13 Mai 2020, 15:45:32

Zitat von: KölnSolar am 13 Mai 2020, 14:58:56
Und die vorangegangene Nacht war ja schon kurz.

Oh ja

Zitat
Aber prima, dass es wieder geht. Jetzt aber schnell noch ein image erstellen....

Ist gemacht !

Zitat
Klingt dann ja irgendwie nach Netzwerkproblem(Ursache "verwirrte" FritzBox $:-\$ ).

Tja. Nix genaues weiss man nicht. Leider.
Die Ursache wird wohl keiner mehr feststellen können (zumindest ich nicht).

Zitat
Deshalb solltest Du meinen Hinweis zu global dnsServer umsetzen, denn dadurch verhinderst Du blockierendes Verhalten bei Netzwerkzugriffen.

Auf was und wie sollte ich den denn setzen ? Einfach "attr global dnsServer" ? Müsste mich da erst noch einlesen, verstehe das Attribut noch nicht wirklich. Bedeutet das, dass fhem einen eigenen Nameserver betreibt ? Woher dann die Domainname-IP-Zuordnung ? Werden da einfach die IPs bisheriger DNS-Anfragen gespeichert ?

Zitat
Und freezemon anstatt perfmon einzusetzen wäre auch nicht verkehrt, denn dann sollte der Verursacher von freezes angezeigt werden, wodurch sich auf Netzwerkprobleme schließen ließe.

Tja. Geht nicht. Mein FHEM ist zu alt (fhem.pl aus 2016), da kann man nicht einfach irgendwelche neuen Modul einbinden.

Und einfach updaten geht nicht, Tablet UI wird über Apache bedient, die Dateien stehen in keinem Standardverzeichnis mehr, Mosquitto ist eine alte Version weil nur die es für meinem alten Rasbian gab, ich hab die Standard .css für Tablet UI editiert anstatt die userdatei und und und. Viel gestrickt, da blickt keiner mehr durch.

Aufgeräumt wird das ganze mit einem großem Update und das gibt es erst zusammen mit einem Hardware-Upgrade.
Wahrscheinlich der nächsthöhere Raspi mit viel GB RAM bei dem SSD-Booten standardmäßig (wieder) geht.
Oder wenn mein FHEM den Dienst verweigert so wie gestern - ich stand kurz vor dem Abgrund (bzw. einem Upgrade auf Raspi3 )

rasti · 13 Mai 2020, 15:57:07

Zitat von: Otto123 am 13 Mai 2020, 15:35:42
Naja wenn es nicht die SD Card war und auch nicht das Netzteil (Stecker/Kabel?) - äußert sich beides eigentlich massiver $:-\$

Dann tippe ich ich auch nach wie vor auf "Netzwerkkabel" - symbolisch gemeint und unterschreibe alle Ideen von Markus

Habe eben festgestellt, dass mein Onkyo und mein Volumio-Raspi auch nicht mehr taten was sie sollten. Habe die vom Strom genommen und neu booten lassen. Dass die nicht gelaufen sind war mir gar nicht aufgefallen, da ich die mit den Fingern gar nicht mehr angreife sondern grundsätzlich über Tablet UI steuere. Spricht auch für Netzwerkprobleme, die mein FHEM zum Absturz gebracht haben....