RPi3 nicht zugreifbar - scheinbar extrem hohe plötzliche Systemlast

Begonnen von KölnSolar, 22 November 2016, 09:29:16

Vorheriges Thema - Nächstes Thema

KölnSolar

Ich bräuchte dann auch mal Hilfe: Heute Morgen konnte ich kaum noch auf fhem bzw. den Rpi zugreifen. Was heißt kaum ? Putty und WinSCP nicht möglich. fhem im Browser ansprechbar, aber keine Bilder, sondern nur Textzeilen werden angezeigt, so wie man das schon mal bei schlechten Serververbindungen gesehen hat. Mein fhem-Infodisplay lief noch perfekt, weil es ja seine Seite auf dem Client aufbaut. Ins Auge fiel mir eine Statuszeit von 2:22 eines devices. Soweit die Symptome und meine Einschätzung: System zu 99,9% ausgelastet.

Was tun ? Restart. Also ein shutdown fhem und dann Stecker ziehen. Es passiert......nichts. Dieses 2. Problem hatte ich nun auch schon öfter. Deshalb bin ich auch vor ein paar Monaten von SD auf USB-Stick umgestiegen. Zig mal in den verschiedensten Konstellationen ohne Peripherie rebootet......nix. Die grüne LED zeigt nicht ein einziges mal Ihr Licht :( SD-Karte rein und plötzlich, oh Wunder, er bootet und blinkt mich freundlich an. Wieder runter gefahren USB-Stick dran und siehe da, bootet auch wieder ?!?!? Da bin ich mit meinem Latein am Ende. Was verhindert denn bei den anderen Versuchen den reboot meines RPi3 mit aktuellem Jessie ?

Zurück zum 1. Problem. In fhem erkenne ich nach dem reboot, dass die letzten Datenlogs um 2:22 erstellt wurden. Ahh deckt sich mit dem timestamp, den ich im Infodisplay sah. Stromausfall ? No, die Fritte ist heute Nacht nicht neu gestartet. Also mal ein Blick ins Systemlog. Hier nur ein kurzer Auszug:
Nov 21 20:17:01 raspberrypi CRON[25644]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Nov 21 21:17:01 raspberrypi CRON[25771]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Nov 21 22:17:01 raspberrypi CRON[25904]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Nov 21 23:17:01 raspberrypi CRON[26035]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Nov 22 00:17:01 raspberrypi CRON[26163]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Nov 22 01:17:01 raspberrypi CRON[26291]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Nov 22 02:17:01 raspberrypi CRON[26418]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)

Nov 22 02:17:05 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="469" x-info="http://www.rsyslog.com"] start
Nov 22 02:17:05 raspberrypi kernel: [    0.000000] Booting Linux on physical CPU 0x0
Nov 22 02:17:05 raspberrypi kernel: [    0.000000] Initializing cgroup subsys cpuset
Nov 22 02:17:05 raspberrypi kernel: [    0.000000] Initializing cgroup subsys cpu
Nov 22 02:17:05 raspberrypi kernel: [    0.000000] Initializing cgroup subsys cpuacct
Nov 22 02:17:05 raspberrypi kernel: [    0.000000] Linux version 4.4.17-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #902 SMP Mon Aug 15 12:21:29 BST 2016
Nov 22 02:17:05 raspberrypi kernel: [    0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d

Nov 22 02:17:14 raspberrypi systemd[1]: Starting Update UTMP about System Runlevel Changes...
Nov 22 02:17:14 raspberrypi systemd[1]: Started Update UTMP about System Runlevel Changes.
Nov 22 02:17:14 raspberrypi systemd[1]: Startup finished in 9.986s (kernel) + 14.606s (userspace) = 24.592s.
Nov 22 02:17:19 raspberrypi dhcpcd[707]: eth0: no IPv6 Routers available
Nov 22 07:09:59 raspberrypi systemd[1]: Time has been changed

2:17 letztmalig den cron-job ausgeführt. Danach kommt als erster Eintrag, etwas verwirrend, mit 2:17 die Meldungen über "einen" Reboot. Tatsächlich ist das aber der reboot von heute Morgen, aber erst später wird die Systemzeit auf aktuellen Stand gebracht.

Da sich also keinerlei Informationen über den Grund der Überlastung des Rpi und damit (Teil-)Ausfall von fhem finden lassen, was könnte man ins systemlog oder sonst wohin schreiben lassen, um der Ursache näher zu kommen ? Ich dachte an sowas wie die ersten 2 Zeilen von top in ein log zu schreiben.

Als letzte Info noch zu meinem System: War tagelang gelaufen. Außer fhem läuft nichts an Anwendung auf der Kiste. Lt. top in der Regel deutlich unter 10% CPU. Lediglich ein paar kworker/u8:2, kworker/u8:3 kworker/u8:0 treiben Ihr "Unwesen" mit um die 10% Last. Im Inet hab ich nix gefunden, um rauszufinden, was da den Kernel zu den Prozessen veranlasst. Komischerweise wechselt die PID auch noch ?! Wären wir also bei Problemchen Nr. 3. Ich würd ja mal ohne fhem-start booten und gucken wollen, ob die kworker mit fhem im Zusammenhang stehen, aber dann hab ich ja wieder Problem Nr. 2  :'(

Jemand Ideen zu meinen 3 Problemen ?

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

frank

Zitatfhem im Browser ansprechbar, aber keine Bilder, sondern nur Textzeilen werden angezeigt, so wie man das schon mal bei schlechten Serververbindungen gesehen hat.
das hatte ich neulich auch, als ich nach ein paar tagen wieder nach hause kam. logs endeten alle während meiner abwesenheit.

fhem shutdown (restart automatisch über systemd) über eingabezeile hat keine besserung gebracht. im gegenteil, nun war fhem gar nicht mehr erreichbar, als hätte nur shutdown funktioniert. nach einem reboot des pi (stecker ziehen) war wieder alles ok.

ich vermute bei mir ein problem mit der wlan verbindung, eventuell im zusammenspiel mit der fritzbox als wlan router. habe ich aber nicht näher untersucht. allerdings frage ich mich gerade nach dem zusammenhang von wlan mit den logs, die auf dem pi angelegt werden.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

KölnSolar

Zitatbei mir ein problem mit der wlan verbindung
Könnte eine Möglichkeit sein. Ich hab zwar eine LAN-Verbindung, aber das WLAN ist aktiv und in der Fritte angemeldet. Wer weiß, ich schalte einfach mal explizit das WLAN ab und beobachte weiter.
Danke für die Hilfe. Zu den beiden anderen Problemen jemand noch ne Idee ?
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Thorsten Pferdekaemper

Hi,
meine RasPi3-Experimente haben zwei Probleme/Schwachstellen hervorgebracht:
1. Das WLan ist nicht wirklich sehr stabil. Man scheint das Ding dann und wann mal durchstarten zu müssen.
2. Das Teil entwickelt mehr Hitze als bisherige RasPis.
Der zweite Punkt könnte diverse Folgeprobleme hervorrufen, daher poste ich das hier. Hast Du mal nachgeschaut bzw. aufgezeichnet, wie warm das Teil wird?
Gruß,
   Thorsten
FUIP

KölnSolar

Danke für die Rückmeldung.
ZitatDer zweite Punkt könnte diverse Folgeprobleme hervorrufen, daher poste ich das hier. Hast Du mal nachgeschaut bzw. aufgezeichnet, wie warm das Teil wird?
leider nicht. Steht aber im Keller bei derzeit um die 16° und nicht in ein Gehäuse "gezwängt". Sollte doch hoffentlich keine Probleme verursachen.

Bin aber schon Schritte weiter.
Der reboot-Verhinderer(Problem 2) ist identifiziert. Es liegt irgendwie an den angeschlossenen USBs. Entweder macht ein passiver Hub Probleme oder eine Kabelverbindung ist irgendwie nicht in Ordnung.

Problem 1 ist erneut aufgetaucht, nachdem ich versuchte den WLAN-Adapter zu deaktivieren über "sudo ifwlan0 down", mit iwconfig zum überprüfen und dann dachte ich, stell ich es über raspi-config zur Bootzeit ab. Aber da gibt es gar keine Möglichkeit. Und dann war das Problem plötzlich wieder da. Leider kriege ich es aber nicht nachgestellt  >:( Möglicherweise ist aber auch ein Zusammenhang mit dem USB(Problem 2) ?

Nachdem ich jetzt so langsam wieder aufatme: Habt Ihr auch diese kworker-Prozesse(Problemchen 3) und wisst vielleicht, was die treiben ?

Bis zu euren Antworten kümmere ich mich um den WLAN-Adapter....
Markus


RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

renardfm

ich kenne die Probleme auch.
Bei mir war der Raspi3 dann aber auch nicht mehr über SSH ansprechbar. Am Anfang trat es oft auf, wenn ich große Logfiles über den Browser geöffnet oder schnell die Seiten gewechselt habe.
Da half nur Stecker ziehen. Der Pi ist in einem Gehäuse und um die 50°C warm. Versuchsweise habe ich es offen gelassen (40°C), aber es hat keinen Unterschied gemacht.

Ich habe dann ein apt-get update gemacht + fhem update und jetzt auch mal alte Logfiles in den Ordnern gelöscht. Seitdem scheint es zu gehen. Es gibt wohl auch einen Powersave Modus beim WLAN des RPi3, den man deaktivieren sollte.

Gruß, Florian

KölnSolar

gerade ist es mal wieder passiert. Diesmal aber etwas andere Symptome: 74h uptime, ssh u. sftp problemlos. fhem: nicht mehr erreichbar. fhem stop funktioniert nicht. Erst mit kill -9 und nachfolgendem fhem start ist wieder alles ok. Logs wurden nicht mehr fortgeschrieben, auch nicht fhem.log  >:( vorgenommene Änderungen: neues device für SYSMON, Modulupdates.
Jemand ne Idee, warum fhem den Zugriff verweigern könnte bzw. was ich machen kann, um der Ursache auf die Schliche zu kommen ?
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

frank

bei mir ist es gerade erstmalig passiert, während ich auf den pi über putty/ssh zugegriff hatte und ein perl modul installieren wollte. die putty ausgabe hängt, es geht nicht weiter:
root@raspberrypi:/home/pi# apt-get install libcrypt-rijndael-perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  libcrypt-rijndael-perl
0 upgraded, 1 newly installed, 0 to remove and 45 not upgraded.
Need to get 21.1 kB of archives.
After this operation, 34.8 kB of additional disk space will be used.
Get:1 http://mirrordirector.raspbian.org/raspbian/ jessie/main libcrypt-rijndael                                                                              -perl armhf 1.12-1+b1 [21.1 kB]
Fetched 21.1 kB in 0s (41.4 kB/s)
Selecting previously unselected package libcrypt-rijndael-perl.
(Reading database ... 34729 files and directories currently installed.)
Preparing to unpack .../libcrypt-rijndael-perl_1.12-1+b1_armhf.deb ...
Unpacking libcrypt-rijndael-perl (1.12-1+b1) ...
Processing triggers for man-db (2.7.0.2-5) ...


um zu sehen, ob der pi noch läuft, habe ich im browser nach fhem geschaut. 2 bereits geöffnete tabs zeigen keinen verbindungsabbruch und longpoll funktioniert weiterhin. ein weiterer neuer fhem tab wird dann aber nur im "text-design" dargestellt. dort, wo plots sein sollten, wird eine fehlermeldung gezeigt:
Cannot read ./www/gplot/SVG_FileLog_sysmon_1.gplot

edit:
irgendwie scheint zumindestens fhem keinen zugriff mehr auf das dateisystem zu haben. die fhem eingabezeile im "text-design" funktioniert jedenfalls, sodass ich befehle ausführen kann. firebug zeigt probleme mit sämtlichen dateien (screenshot), wie png, js, css, ... dazu passt ja auch, dass die log-files nicht geschrieben werden.

interessant ist vielleicht auch, dass die fhem zeit jetzt exakt 1 stunde zurück ist. auch localtime über fhem zeigt es.

über putty/ssh komme ich weiterhin nicht auf den pi, aber ich komme über putty/telnet auf den fhem-telnet zugang über port 7072.

fhem funktioniert bei mir weiterhin extrem gut, dass heisst, es können keine freezes etc auftauchen, denn meine heizungsventile werden von fhem bedient und die benötigen ein äusserst exaktes timing. auch empfängt ein usb-cul433 am pi eine intertechno fernbedienung, womit dann in fhem ein homematic aktor geschaltet wird. völlig problemlos und verzögerungsfrei.


hat vielleicht jemand eine idee, was ich jetzt gerade versuchen könnte, um weitere hinweise zu bekommen?

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

mein pi3 ist nun schon ein paar stunden im jetzt-bin-ich-mal-weg-modus. fhem läuft immer noch bestens, bis auf die nicht funktionierenden datei zugriffe.

sysmon zeigt ein paar besonderheiten, gegenüber sonst:

- es gibt jede menge timestamps von heute 10:49, wahrscheinlich der crashzeitpunkt. eventuell wird hier auch auf dateien zugegriffen, was nun nicht mehr möglich ist.
- die temperaturen liegen jetzt bei ca null grad, sonst um 44 mit ein paar spitzen von max 48 und die zeiten sind aktuell. kann dies das problem sein? gibt es eventuell mechanismen, die durch fehlerhafte temperaturwerte bestimmte teile des pi fälschlicherweise lahmlegen?
- die ersten beiden wlan readings haben sonst etwas angezeigt. jetzt sind sie nicht möglich, aber die timestamps sind aktuell.

vielleicht fällt jemandem noch etwas entscheidendes auf, daher anbei die screenshots.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

KölnSolar

seeeehr ähnlich.
Zitateventuell wird hier auch auf dateien zugegriffen, was nun nicht mehr möglich ist.
das ist auch meine Ansicht. Alles läuft gemütlich vor sich hin und bekommt gar nicht mit, dass es ein Problem gibt. Nur auf allertiefster Systemebene klemmt was. Nur was und wo, dass fhem scheinbar glaubt das Logging liefe 1a ?
Mir kommt immer mal wieder der Gedanke, es könne mit der nicht vorhandenen rtc zusammenhängen. Kannst Du externe Server, insbesondere die ntp-server anpingen ?
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

frank

jetzt habe ich schon den stecker vom pi gezogen und alles ist wieder normal.
ich hatte irgendwie keine möglichkeit über fhem auf systemebene zuzugreifen. alle mir bekannten möglichkeiten verliefen im sande. nächstes mal vielleicht.  :)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

KölnSolar

verstehe ich.  ;D kein Logging ist Käse. Ich fand Dich schon extrem geduldig. Wenn ich es wieder hab, probier ich es auch mal mit telnet bevor ich ungeduldig reboote  ;D
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Wernieman

Das hört sich danach an, das der Pi nicht mehr auf seine "speichermöglichkeiten" zugreifen konnte. Alle bis dahin laufenden prozesse laufen noch. Logging ist natürlich nicht möglich.

Wenn ich recht habe, ist aber auch ein login nicht möglich, da meistens nicht im Speicher vorhandene Daten auf dem externen Medium (z.B: SDCarte) zugegriffen werden muss, was ... s.o.

Trotzdem:
Vor einem reboot sollte man immer prüfen:
- ist der Rechner noch erreichbar (z.B: ping)
  - ist der Rechner noch per ssh erreichbar
    - ist ein einloggen möglich
      - weitere Fehlersuche ...
  - Wenn kein ssh, was laufen an sonstigen Netzwerkdiensten (z.B: per nmap prüfen)
    - .....
- Wenn nicht pingbar, ssh etc. was sagt denn eine Bildschirmausgabe (Bildschirm/Tastatur anschließen
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

frank

Zitat von: Wernieman am 29 November 2016, 09:47:26
Das hört sich danach an, das der Pi nicht mehr auf seine "speichermöglichkeiten" zugreifen konnte. Alle bis dahin laufenden prozesse laufen noch. Logging ist natürlich nicht möglich.

Wenn ich recht habe, ist aber auch ein login nicht möglich, da meistens nicht im Speicher vorhandene Daten auf dem externen Medium (z.B: SDCarte) zugegriffen werden muss, was ... s.o.
so stell ich mir das auch vor. hast du denn eine idee, was diesen zustand auslösen könnte?

Zitat- Wenn nicht pingbar, ssh etc. was sagt denn eine Bildschirmausgabe (Bildschirm/Tastatur anschließen
habe leider keine passende hardware zur hand.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Wernieman

Beim Pi: Meistens Probleme mit der SDCarte (Karte, Kontackte etc.)
Bei anderen Systemen: HDD kaputt, wenn über USB gebootet, USB-Probleme
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html