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

[willybauss]

... Ich denke eher es liegt an der Art der Abfrage...

Das war auch mein Gedanke. Ich habe mal beim Entwickler von PiControl nachgefragt, wie er die Abfrage macht. Vielleicht hilft das ja.

edit:
PiControl nutzt dieselbe Abfrage

Code Auswählen Erweitern

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

Dann kann ich mir höchstens vorstellen, dass man die Reihenfolge der Abfragen in Symon optimieren könnte, om die CPU-Freq. Abfrage zuerst zu haben.

[nesges]

Seit ein paar Tagen habe ich folgende Meldung im Log:

Code Auswählen Erweitern

2015.05.21 08:59:18 1: PERL WARNING: Can't exec "ifconfig": Datei oder Verzeichnis nicht gefunden at ./FHEM/42_SYSMON.pm line 3969.

Die Meldung war hier schonmal Thema, damals war's aber offenbar ein Rechteproblem, das ich ausschliessen kann. Leider kann ich aber nicht nachvollziehen, was sich am System geändert hat. Das letzte Fhem-Update ist auf jeden Fall schon länger her. Ursache scheint zu sein, dass ifconfig nicht gefunden wird. Wenn ich in Zeile 2538 den Pfad ergänze funktioniert's:

Code Auswählen Erweitern

my $cmd="/sbin/ifconfig ".$device." 2>&1";

Dabei läuft mein Fhem als User fhem, und der hat /sbin im $PATH. Wenn jemand eine Idee hat, woran's liegen könnte, wäre ich für Tipps dankbar.

Hier noch die Details:

Code Auswählen Erweitern

define SYSMON SYSMON
attr SYSMON event-on-change-reading .*
attr SYSMON group Helper
attr SYSMON room System

Code Auswählen Erweitern

root@wopr:~# ps -ef | grep fhem
fhem     15522     1  6 13:44 ?        00:02:09 /usr/bin/perl fhem.pl fhem.cfg
fhem     15586 15522  0 13:45 ?        00:00:00 /usr/bin/perl fhem.pl fhem.cfg
fhem     15588 15522  0 13:45 ?        00:00:00 /usr/bin/perl fhem.pl fhem.cfg
fhem     15589 15522  0 13:45 ?        00:00:00 /usr/bin/perl fhem.pl fhem.cfg
fhem     15590 15522  0 13:45 ?        00:00:00 /usr/bin/perl fhem.pl fhem.cfg
fhem     15591 15522  0 13:45 ?        00:00:00 /usr/bin/perl fhem.pl fhem.cfg
root     18207 24675  0 14:17 pts/0    00:00:00 grep fhem
root@wopr:~# su - fhem
fhem@wopr:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
fhem@wopr:~$ ifconfig
eth0      Link encap:Ethernet  Hardware Adresse b8:27:eb:68:f2:f7
          inet Adresse:192.168.178.64  Bcast:192.168.178.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:24001989 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15367583 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:2179012672 (2.0 GiB)  TX bytes:2365126648 (2.2 GiB)

lo        Link encap:Lokale Schleife
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX packets:4906666 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4906666 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:563295227 (537.2 MiB)  TX bytes:563295227 (537.2 MiB)

fhem@wopr:~$


[hexenmeister]

Das bedeutet, dass {qx('ifconfig')} in FHEM-Console nicht funktioniert, aber {qx('/sbin/ifconfig')} schon?
Und in der Linux-Console geht beides?
Das ist schon sehr sonderbar.

Nur zur Sicherheit, bringt {qx('whoami')} wirklich 'fhem'? Ich hatte schon mal ein Problem, als ich fhem aus der Console manuel gestartet habe (natürlich mit falschem User) und dann diesen Umstand ganz vergessen habe...

[nesges]

Genau so ist es, und {qx('whoami')} bestätigt den User fhem. Habe grade noch "ifconfig" und "/sbin/ifconfig" in Fhem ausprobiert. Das Ergebnis landet dabei jeweils im fhem.log:

"ifconfig":

Code Auswählen Erweitern

sh: 1: ifconfig: not found

"/sbin/ifconfig":

Code Auswählen Erweitern

eth0      Link encap:Ethernet  Hardware Adresse b8:27:eb:68:f2:f7
          inet Adresse:192.168.178.64  Bcast:192.168.178.255  Maske:255.255.255.0
[...]

Das hat dann wohl auch weniger mit SYSMON als generell mit der Userumgebung innerhalb Fhems zu tun.

Edit: Auch interessant:
". ~/path.sh"

Code Auswählen Erweitern

sh: 1: .: Can't open /root/path.sh

[hexenmeister]

Hm. Mit SYSMON hat das definitiv nichts zu tun. Bin leider überfragt. Schon mal das alte hausfrauenmittel (auch bekannt als reboot) ausprobiert?

[Wernieman]

Das bedeutet, das Dein User nicht /sbin im Pfad hat, also Linux nicht nach dem "Programm" ifconfig in /sbin sucht. Also ... entweder /sbin mit in den Pfd aufnehmen, oder unter /usb/nin einfach einen Link setzen ;o)

[nesges]

Das bedeutet, das Dein User nicht /sbin im Pfad hat, also Linux nicht nach dem "Programm" ifconfig in /sbin sucht. Also ... entweder /sbin mit in den Pfd aufnehmen, oder unter /usb/nin einfach einen Link setzen ;o)

Ach? Das ist schon klar, die Frage war warum das so ist.

Offenbar ist das was fhem.pl ab Zeile 383 macht nicht ausreichend um den Usercontext zu wechseln. Die Effekte sind wie oben beschrieben. Ich habe letztlich /etc/init.d/fhem (wird mit dem Debian Package ausgeliefert) angepasst und starte jetzt mittels su:

Code Auswählen Erweitern

su fhem -c "perl fhem.pl fhem.cfg &"

[hexenmeister]

Hm... Da bei mir in /etc/init.d/fhem schon ewig "sudo -u fhem ..." steht, habe ich diesen Effekt natürlich nie gehabt...

[willybauss]

Um auf das CPU-Frequenz-Thema zurückzukommen:

Ich habe mal einen Versuch mit SYSSTAT statt SYSMON gemacht, und dort wird die Frequent korrekt angezeigt, also meist 700MHz, nur bei Last kurzzeitig 1000MHz.

Hilft Dir das bei der Ursachenermittlung weiter?

[hexenmeister]

Ich weiß mittlerweile, woran das liegt. Nachsehen bei SYSSTAT bestätigt das noch einmal.
Es funktioniert nicht richtig, wenn man während oder gleich nach einem BlockingCall die Frequenz liest. Scheibar erzeugt das so viel Last, dass CPU immer hochgefahren wird.

Ich habe für diese Funktion eine dreckige Sonderlocke eingebaut. Scheint bei mir zu funktionieren.
Bitte ausprobieren. Kann sein, dass es an einigen Systemen wieder alte Warnings gibt.

[willybauss]

Test läuft seit 1 Stunde - funktioniert einwandfrei  . Zusätzliche Warnings sehe ich bis jetzt keine.

[hexenmeister]

Jut
Dann werde ich heute später abends einchecken.

[hexenmeister]

so. etwas verspätet, aber jetzt eingecheckt.

[Newbee]

Hallo Hexenmeister,

nach update bekomme ich nun folgende Meldung in FHEM angezeigt, wo normalerweise die Balken sind.

Code Auswählen Erweitern

Too many arguments for main::SYSMON_ShowBarChartHtml at (eval 8649) line 1, near "'gray')"

Bekomme keine Fehlermeldung im LOG angezeigt.

Das Balkendiagramm habe ich wie folgt definiert.

Code Auswählen Erweitern

define wlSysmon weblink htmlCode {SYSMON_weblinkHeader('wlSysmon','RPi 2').SYSMON_ShowBarChartHtml('sysmon','steelblue','gray')}
attr wlSysmon group Sys
attr wlSysmon room Pi

Danke vorab.

Grüsse Newbee

[hexenmeister]

Hi!

Die Methoden für die Balkendiagramme haben sich etwas verändert und sind noch experimentell. Langfristig werden sie aus den SYSMON-Modul komplet ausgebaut und von dem Ursprungsentwickler (snx) als extra-Plugin/Modul bereitgestellt.

Grüße,

Alexander