Ein Modul zur Erfassen von diversen RPi/Linux-Statistiken (SYSMON)

[hexenmeister]

Die Last kommt wohl dadurch, dass SYSMON alle Werte je in eigener Conection zu lesen versucht, anstatt eine gemeinsam zu verwenden. Warum das so passiert, kann ich in dem Stück nicht sehen. War FHEM neugestartet?
Wie dem auch sei, ohne die Parameter (Pfade etc.) für dieses System zu kennen, kann ich nichts weiter tun. Ich habe ja diese Hardware selbst nicht.

[Achim]

Hallo,

mein RPi ist heute und gestern komplett abgestürzt. Nicht mal mehr ein Ping ging. Auf der Linux Ebene kenne ich mich nicht aus um dort in irgendwelchen Logs nachzusehen, woher das evtl. kommen könnte.

Auf der FHEM Seite habe ich im Logfile aber folgende Einträge:

2015.04.14 13:09:19 1: Timeout for SYSMON_blockingCall reached, terminated process 31913
2015.04.14 13:10:20 1: Timeout for SYSMON_blockingCall reached, terminated process 31928
2015.04.14 13:11:20 1: Timeout for SYSMON_blockingCall reached, terminated process 31945
2015.04.14 13:12:20 1: Timeout for SYSMON_blockingCall reached, terminated process 31962
2015.04.14 13:13:20 1: Timeout for SYSMON_blockingCall reached, terminated process 31980
2015.04.14 13:14:20 1: Timeout for SYSMON_blockingCall reached, terminated process 31995
2015.04.14 13:15:20 1: Timeout for SYSMON_blockingCall reached, terminated process 32012
2015.04.14 13:16:20 1: Timeout for SYSMON_blockingCall reached, terminated process 32029
2015.04.14 13:17:20 1: Timeout for SYSMON_blockingCall reached, terminated process 32046
2015.04.14 13:18:20 1: Timeout for SYSMON_blockingCall reached, terminated process 32074
2015.04.14 13:19:20 1: Timeout for SYSMON_blockingCall reached, terminated process 32091
2015.04.14 13:20:20 1: Timeout for SYSMON_blockingCall reached, terminated process 32108
2015.04.14 13:21:21 1: Timeout for SYSMON_blockingCall reached, terminated process 32123
2015.04.14 13:22:21 1: Timeout for SYSMON_blockingCall reached, terminated process 32140
2015.04.14 13:23:21 1: Timeout for SYSMON_blockingCall reached, terminated process 32158
2015.04.14 13:24:21 1: Timeout for SYSMON_blockingCall reached, terminated process 32173
2015.04.14 13:25:21 1: Timeout for SYSMON_blockingCall reached, terminated process 32190
2015.04.14 13:26:21 1: Timeout for SYSMON_blockingCall reached, terminated process 32207
2015.04.14 13:27:21 1: Timeout for SYSMON_blockingCall reached, terminated process 32224
2015.04.14 13:28:21 1: Timeout for SYSMON_blockingCall reached, terminated process 32242
2015.04.14 13:29:21 1: Timeout for SYSMON_blockingCall reached, terminated process 32259
2015.04.14 13:30:24 1: Timeout for SYSMON_blockingCall reached, terminated process 32276
2015.04.14 13:30:54 0: Server shutdown
2015.04.14 13:17:23 1: Including /etc/fhem.cfg
2015.04.14 13:17:27 3: WEB: port 8083 opened
2015.04.14 13:17:29 3: WEBphone: port 8084 opened
2015.04.14 13:17:29 3: WEBtablet: port 8085 opened
2015.04.14 13:17:31 3: Opening COC device /dev/ttyAMA0
2015.04.14 19:57:57 3: Setting COC baudrate to 38400

Ich habe um 19:57 den RPi per "Stromlos machen" neu gestartet. Die Logeinträge von gestern sehen ähnlich aus. Die "schrägen" Zeiten kommen wohl daher, das ich bei irgendeinem Update vergessen habe, den NTP Dienst vor dem FEHM automatisch zu starten. Die letzten Einträge in den anderen FHEM-Logs sind von 13:30:xx

Da die Logeinträge auf den SYSMON warten und zu diesem Zeitpunkt das System noch läuft, gehe ich erstmal von einem Problem mit SYSMON aus. Die Updates von FHEM sind aktuell und das letzte SYSMON Update kam laut Logfile am 07.04. Version 2.1.5

Kann mir da jemand weiterhelfen, bzw. was soll ich an Infos vom System noch liefern um den Fehler weiter einzukreisen oder zu finden?

Meine SYSMON Definition in FHEM ist folgende:

Code Auswählen Erweitern

define sysmon SYSMON 1 1 1 10
attr sysmon event-on-update-reading cpu_temp,cpu_temp_avg,cpu_freq,eth0_diff,loadavg,ram,fs_.*,stat_cpu_percent
attr sysmon filesystems fs_boot:/boot,fs_root:/:Root
attr sysmon network-interfaces eth0:eth0:Ethernet

Viele Grüße
Achim

[hexenmeister]

An SYSMON-Problem glaube ich hier nicht. Die Einträge besagen, dass die von SYSMON gestarteten Tasks nicht in der vorgesehenen Zeit beendet wurden und daher abgebrochen waren. Die Tasks starten Betriebssystem-Befehle, die die notwendigen Informationen zurückliefern. Warum das so ist, kann ich nur raten. Dazu steht hier nichts. Passt aber zu Deiner Aussage, dass nicht mal Ping ging. Wenn es schon so weit ist, kann FHEM sicher keine Prozesse mehr starten. Sysmon ist hier die Folge, nicht die Ursache.

Läuft evtl. ein anderes Programm Amok? Wie sehen dabei Speicher-Auslastung und System-Load aus?
Du kannst ja probeweise Sysmon deaktivieren, oder  BlockingCall für Sysmon abschalten (attr <sysmon_name> nonblocking 0).

[hexenmeister]

Hat zwar länger gedauer, aber jetzt ist hier eine Testversion mit Werten für:
- Geschwindigkeit der Netwerk-Verbindung
- erste min/max/avg-Werte: cpuX_freq_stat und cpuX_idle_stat (jeweils drei Werte: min, max, avg)

[Achim]

Hallo,

eine kurze Rückmeldung zu meinem RPi Absturzproblem. Leider/glücklicherweise ist der RPi ohne Änderungen (außer FHEM Updates und Debian Updates) nicht mehr abgestürzt. Problem weg ohne das man genau weiß woher es kam gehört nun nicht zu meinen bevorzugten Problemlösungen. Kann ich nur hoffen das es nicht nochmals auftritt. Vielen Dank für die Bemühungen.

Viele Grüße
Achim

[Basti]

Hallo,

ich habe gerad ein Update vorgenommen (von Version 8185 vom 2015-03-09) und jetzt bekomme ich bei jedem Sysmon Update folgende Warnungen im Log:

Code Auswählen Erweitern


2015.04.23 14:31:55.399 1: PERL WARNING: Argument "cat: /sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_fr..." isn't numeric in int at ./FHEM/42_SYSMON.pm line 1714.
2015.04.23 14:31:55.438 1: PERL WARNING: Argument "cat: /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_fr..." isn't numeric in int at ./FHEM/42_SYSMON.pm line 1714.


Es scheint als ob es auf meinem ODroid U3 für cpu2 und cpu3 kein cpufreq Verzeichnis existiert. Das gibts nur für cpu0 und cpu1 (welches auf das von cpu0 verweist).

Gibt es eine Möglichkeit Sysmon auf cpu0 und cpu1 zu beschränken?

Danke,
Sebastian

EDIT: Es scheint, der Fehler tritt nur auf, wenn cpu2 und cpu3 in Nutzung sind. Wenn das System keine Last hat, werden die cpu's anscheinend nicht abgefragt.

[hexenmeister]

SYSMON fragt nicht abhängig von Systemlast.

Was liefern denn

Code Auswählen Erweitern

[ -f /sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq ] && echo 1 || echo 0
und

Code Auswählen Erweitern

[ -f /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq ] && echo 1 || echo 0

Was kommt, wenn man die Datei in der Console ausgibt?

[Basti]

Hallo,

danke für die schnelle Antwort. Ich meinte auch das mein Board die CPU 2 und 3 abschaltet wenn keine Last besteht.

Beide Kommandos geben 0 auf der Konsole aus (mit CPU2+3 nicht aktiv).

Allerdings scheint sich das Problem selbst behoben zu haben - zumindest gibts im Log keine weiteren Perl warnings bezüglich der cpufreq.

Ich meld mich nochmal, falls die Warnungen doch wieder auftauchen sollten.

Gruß,
Sebastian

[snx]

Hat zwar länger gedauer, aber jetzt ist hier eine Testversion mit Werten für:
- Geschwindigkeit der Netwerk-Verbindung
- erste min/max/avg-Werte: cpuX_freq_stat und cpuX_idle_stat (jeweils drei Werte: min, max, avg)

passt auf den ersten Blick, hab allerdings 2 Anmerkungen:

- Alle Netzwerk-Geschwindigkeit Readings (*_speed) liefern bei Fritz-Box folgenden Fehler: cat: can't open '/sys/class/net/*/speed': No such file or directory
Das sollte abgefangen werden.

- Die Durchschnittsermittlung (avg*3 + cur)/4 ist recht ungenau. Was spricht gegen das Zählen der Einzelwerte, wodurch es genau wird?

[hexenmeister]

Hm, schade, Fritte hat leider kein 'speed'. Muss ich abfragen und unterbinden.

Durchschnitt ist ja per Definition ungenau. Alle Werte zu zählen ist aufwendiger und birgt eine Gefahr des Überlaufs (ok, erst nach sehr langer Zeit). Meine Formal ist übrigens nicht wirklich schlechter, denn es wird genauso jedes Wert berücksichtigt.

P.S. Andere min/max Werte werde ich noch nachliefern.

[hexenmeister]

Die bereits angesprochenen Änderungen sind morgen per Update verfügbar.
Zusätzlich noch: cpu_temp_stat
Warnungen wg. scaling_cur_freq  und eth0/speed sollten weg sein.

[Harald]

Hallo Hexenmeister,

ist es möglich mit SYSMON neben  der Laufzeit seit Start auch die Startzeit des Systems bzw. FHEM als Text anzuzeigen? Man müsste dann nicht nachrechnen, wann gestartet wurde.

Viele Grüße und vielen Dank im Voraus

Harald

[snx]

Die bereits angesprochenen Änderungen sind morgen per Update verfügbar.
Zusätzlich noch: cpu_temp_stat
Warnungen wg. scaling_cur_freq  und eth0/speed sollten weg sein.

Die Warnungen sind weg, aber eine Sache ist mir doch aufgefallen:
Das Reading cpu_freq_stat (ohne CPU-Zählnummer) fehlt.

[hexenmeister]

ist es möglich mit SYSMON neben  der Laufzeit seit Start auch die Startzeit des Systems bzw. FHEM als Text anzuzeigen? Man müsste dann nicht nachrechnen, wann gestartet wurde.

Wozu brauchst Du das?
Aber gut, nach dem Update: starttime, starttime_text, fhemstarttime, fhemstarttime_text

Grüße,

Alexander

[hexenmeister]

Die Warnungen sind weg, aber eine Sache ist mir doch aufgefallen:
Das Reading cpu_freq_stat (ohne CPU-Zählnummer) fehlt.

Danke, morgen gibt es die auch.

Grüße,

Alexander