[ERLEDIGT] FHEM wird nach Neustart nach und nach träger (Load geht nach oben)

[M.Piet]

Hallo Zusammen,
ein seltsames, für mich nicht greifbares Problem habe ich seit kurzem.
FHEM wird nach einem Neustart immer mehr träge und Load geht nach oben. Es scheint (wie man am Screenshot sehen kann) Schrittweise zu passieren.

Gemerkt habe ich es, weil in FTUI oft Sachen nicht (oder nur sehr lang) geladen haben und immer wieder Meldungen vom PRESENCE-Modul kamen, dass Geräte Offline sind. In den Logs auch gut zu sehen, dass es zu Timeouts kommt.
Weiter ist die CPU-Temperatur auch viel höher, als sie sonst es war.

Code Auswählen Erweitern

2024.09.29 07:28:33 3: DS2438_DCDE84000003: reading VAD did not return a value
2024.09.29 07:28:33 3: DS2438_DCDE84000003: reading VDD did not return a value
2024.09.29 07:28:34 1: Timeout for PROPLANTA_Run reached, terminated process 3063
2024.09.29 07:28:46 3: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 3225
2024.09.29 07:28:46 3: PRESENCE (AP_Scheune) - device could not be checked (retrying in 10 seconds): Timeout: process terminated
2024.09.29 07:28:46 3: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 3226
2024.09.29 07:28:46 3: PRESENCE (AP_Dachgeschoss) - device could not be checked (retrying in 10 seconds): Timeout: process terminated
2024.09.29 07:29:26 1: Timeout for SYSMON_blockingCall reached, terminated process 3259
2024.09.29 07:29:40 3: Timeout for FRITZBOX_Readout_Run_Web reached, terminated process 3291
Auch die 1wire Kommunikation macht zunehmend Probleme:

Code Auswählen Erweitern

2024.10.01 07:21:10 3: DS2438_DCDE84000003: reading VDD did not return a value
2024.10.01 07:21:10 3: DS2438_DCDE84000003: reading temperature did not return a value
2024.10.01 07:21:28 3: DS18B20_DBDE84000003: reading temperature did not return a value
2024.10.01 07:23:12 3: DS2438_DCDE84000003: reading VAD did not return a value
2024.10.01 07:31:26 3: DS2438_DCDE84000003: reading VAD did not return a value
Da belegen ein paar Prozesse ganz schön viel CPU-Last.
Jemand eine Idee, wie ich der Ursache auf die Schliche komme?
Soll ich noch ein paar Logs posten?

Vielen Dank für die Hilfe!

[tomcat.x]

Hm, wenn ich mir den Speicherverbrauch ansehe, hast Du vermutlich außer fhem nicht viel oder gar nichts darauf laufen. Aber was sind die vielen python Prozesse?

[M.Piet]

Richtig. Eigentlich nur FHEM und für 1wire der OWFS.
Aber leider habe ich keine Ahnung, warum so viele python Prozesse da sind. Wie komme ich dem auf die Spur?

[MadMax-FHEM]

Wie komme ich dem auf die Spur?

Hast du z.B. fhem Module in Betrieb, die "unterlagert" python nutzen, z.B.: https://forum.fhem.de/index.php?topic=115230.0

Gruß, Joachim

[M.Piet]

Wie komme ich dem auf die Spur?

Hast du z.B. fhem Module in Betrieb, die "unterlagert" python nutzen, z.B.: https://forum.fhem.de/index.php?topic=115230.0

Wüsste nicht, dass ich sowas mal mit eingebaut habe.

Der Fehler ist auch erst seit ca. 1-2 Wochen da. Ich habe in der Zeit nichts verändert, woran ich mich so erinnern kann. Schon gar nicht was in python.

[MadMax-FHEM]

Wüsste nicht, dass ich sowas mal mit eingebaut habe.

Naja, eingebaut.
Wenn das python mal installiert ist, sind es "danach" auch nur fhem Module/Devices...

Was "sagt" denn:

Code Auswählen Erweitern

update list
im Fhem-Web-Eingabefenster?

Die Fehlermeldungen sehen fast alle nach "Netzwerk" aus?
Und v.a. nach "forking" -> es werden Prozesse im Background gestartet -> Speicher, CPU, ...
Und einige (alle) werden mit Timeout abgebrochen.

Dabei sind eben z.B. ping -> PRESENCE?
PROPLANTA
SYSMON
FRITZBOX
...

Wenn du auf dem fhem Rechner bist (ssh-Console), kannst du die Geräte, die du mit PRESENCE/ping überwachst anpingen?
Oder generell "ins Netz"?
Z.B. ping google.de etc.

Irgendwas im Netzwerk geändert?

Gruß, Joachim

[M.Piet]

Danke für deine Hilfe. 😊

update list bringt folgendes:

http://fhem.de/fhemupdate/controls_fhem.txt
https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt
https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt
https://raw.githubusercontent.com/kc-GitHub/FHEM-HM485/master/controls_hm485.txt
https://raw.githubusercontent.com/ThorstenPferdekaemper/FHEM-FUIP/master/controls_fuip.txt
https://raw.githubusercontent.com/knowthelist/ftui/master/controls_ftui.txt

Ich habe länger einen Ping laufen lassen, es gibt keine Peaks nach oben. Läuft sauber durch. Es gab auch keine Änderungen im Netzwerk. Haben Glasfaser 500Mbit und der ist sauber.
Aber da auch anscheinend 1wire mit den hohen Load zu kämpfen hat, ebenso FTUI3, glaube ich auch nicht an ein Netzwerkproblem.

Bin echt ratlos.

Kann man nicht irgendwie über die PID dahinterkommen, wie die  Prozesse gestartet wurden?

[MadMax-FHEM]

update list bringt folgendes:

Ok, dann ist zumindest wohl pythonbinding nicht genutzt...

Ich habe länger einen Ping laufen lassen, es gibt keine Peaks

ping VOM fhem-Rechner zu einem der "überwachten" (PRESENCE) Rechner?
Und das ging durch?

Weil es ja in deinem Log so aussieht, als ob ping (aus PRESENCE) nicht (gut) ginge...

Glasfaser ist ja erst vom Haus ab weg...
...oder hast du lokal auch alles mit Glasfaser?

Der Verdacht war/ist, dass irgendwas bzgl. Netzwerk AUF dem fhem-Rechner "schief" ist, weil es eben so viele Meldungen von Unterprozessen/Devices gibt, die irgendwas mit Netzwerk machen...

IP-Range (INTERN) geändert und z.B. vergessen global dnsServer anzupassen? Ist das Attribut dnsServer bei global überhaupt gesetzt?

Gruß, Joachim

[M.Piet]

Ja, der Ping ging sauber durch.
Ne, Lokal habe ich keine Glasfaser. 😊
Du hast recht, PRESENCE meckert im Log. Aber eher wegen einem Timeout. Ich vermute, dass durch die hohe CPU Last das Modul einen Timeout bekommt. Genau wie 1wire (und das hat ja mit LAN nichts zu tun).

Der DNS unter Global ist gesetzt. 😊

Nach einem Neustart eben war die CPU Arbeitslos. Alles war flott. Nach ein paar Minuten taucht der erste python Prozezz auf, der die CPU zu 100% einnimmt (siehe Screenshot).

[MadMax-FHEM]

Nach einem Neustart eben war die CPU Arbeitslos. Alles war flott. Nach ein paar Minuten taucht der erste python Prozezz auf, der die CPU zu 100% einnimmt (siehe Screenshot).

Tja, wenn du nicht weißt woher die python-Prozesse (plötzlich) kommen (könnten) und du auch (so sieht es aus) kein python aus fhem (z.B. python-binding) nutzt, wird es schwer...

Wenn es langsam ist/wird und du ein:

Code Auswählen Erweitern

sudo killall -9 python
(ja ist rüde/hart aber nur so als Test)
ausführst, wird es dann wieder "flott"?

Ausgeführt werden die python-Prozesse offenbar durch root -> system bzw. ein "Service"?

Gruß, Joachim

[M.Piet]

Code Auswählen Erweitern

sudo killall -9 pythonDas hat (wie erwartet auch geklappt). Aber nach kurzer Zeit ist der Prozezz wieder da. So langsam wird es seltsam.

[sepultura30]

Hi,

installiere dir mal Webmin, da kannst du den Prozess verfolgen bis zum Mutter-Prozess.
Dann siehst du auch was es auslöst.

Grüße

Sandro

[M.Piet]

Hi,

installiere dir mal Webmin, da kannst du den Prozess verfolgen bis zum Mutter-Prozess.
Dann siehst du auch was es auslöst.

Danke!!!! Jetzt kommen wir der Sache näher.
Die entsprechende Datei ultrasonic.py habe ich mal angehangen.

Ich erfasse von Zisterne und Öltank die Pegelstände mit Ultraschallsensoren.
Aber warum macht nun grad aktuell eine davon so einen stress?

Ich habe in dem Zuge damals auch einen Cronjob eingerichtet:

10 0,6,12,18 * * * /home/pi/ultrasonic.py >> /home/pi/zisterne.log

[MadMax-FHEM]

Schon mal in /home/pi/zisterne.log geschaut?
Vielleicht sieht man da was...

Gruß, Joachim

[M.Piet]

Ja, ich bin in der Tat weiter.
Ich kann die Datei mit sudo python ultrasonic.py nicht starten. Es passiert nichts. Aber genau in dem Moment kommt der Prozezz wieder! Das ist also die Ursache!
Und da per Cronjob alle Stunde eine neue Abfrage gemacht wird, entsteht diese Kaskade mit immer neuen Prozezzen!!!

Es gibt noch die Datei ultrasonic2.py, damit frage ich den Stand des Öltanks ab.
Diese kann ich mit sudo python ultrasonic2.py auch korrekt abfragen. Hierbei entsteht nicht dieser Prozezz.

Ich habe beide Dateien mit Notepad vergleichen lassen. Sie sind identisch (mit Ausnahme der GPOIs, siehe unten).
Der einzige Unterschied: Berechtigungen.
ultrasonic.py 644
ultrasonic2.py 755
Das ist aber nicht die Ursache.

Die funktionierende ultrasonic2.py schaut auf diese GPIOs:
GPIOTrigger = 27
GPIOEcho    = 17

Die nicht funktionierende ultrasonic.py schaut auf diese GPIOs:
GPIOTrigger = 24
GPIOEcho    = 23

Kann ein GPIO defekt sein und das auslösen?
Ich werde den Ultraschallsensor auch mal abklemmen und schauen ob es immer noch so ist.

Vielen vielen dank euch allen für die Hilfe bis hier hin!!!!

[M.Piet]

OK, noch eine Erkennis. Ich habe den Sensor abgeklemmt. Trotzdem bleibt wenn ich die beiden ansprechen will:

GPIOTrigger = 27
GPIOEcho    = 17

Ich werde mal andere GPOIs verwenden und weiter berichten.

[M.Piet]

Ein letztes Feedback. Der Fehler ist gefunden.
An dem Ultraschallsensor war der GND ab. Ich hatte da in der Nähe was gearbeitet, und dabei muss er abgegangen sein. Da muss man erstmal drauf kommen. Genauer: dank euch bin ich drauf gekommen. Ich hätte da am allerwenigsten den Fehler vermutet.

Vielen vielen Dank noch mal an alle!!!!