Raspi 3 hängt sich alle zwei bis drei Wochen auf

Begonnen von Dr. Boris Neubert, 27 August 2017, 13:05:15

Vorheriges Thema - Nächstes Thema

Wernieman

Der Vorteil von Swap, das der Kernel nicht benötigte Speicherbereiche (die gibt es IMMER) auslagern kann. Bei dem minimal-Speicher, den der Pi hat, ist dieses nicht zu vernachlässigen!

Ein Rechner, der dauern im Swap ist, hat dagegen ein Grundsätzliches Problem ...
- 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

Bartimaus

Moin,

ich habe bei meinem Presence auch mal deaktiviert und FHEM neu gestartet. RAM-Belegung FHEM: 6,5% nach Neustart.
Jetzt, 3Tage+19h später, ohne in FHEM irgendwas geändert zu haben: RAM-Belegung FHEM: 18,5%....

Keine Ahnung was da los ist...
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

Ma_Bo

Die Beobachtung habe ich auch schon länger gemacht, wenn ich wieder zu Hause bin, kann ich mal nachsehen seit wann das so ist.
Ich habe nämlich noch eine alte Sicherung von Juni glaube ich, da war das noch nicht.

Grüße Marcel


Tapatalk iPhone, daher kurz gehalten.
NUC mit FHEM, HM Heizungsthermostate, HM Wandthermostate, Intertechno Funksteckdosen, 10" Tablet als Wanddisplay, KeyMatic, Fensterkontakte, Fensterkontakte umgebaut als Wassermelder und Briefkastenmelder, Aussenthermostat, Anwesenheitssteuerung über Fritz Box, Google Home usw. usw.

CoolTux

Zitat von: Bartimaus am 04 September 2017, 10:28:52
Moin,

ich habe bei meinem Presence auch mal deaktiviert und FHEM neu gestartet. RAM-Belegung FHEM: 6,5% nach Neustart.
Jetzt, 3Tage+19h später, ohne in FHEM irgendwas geändert zu haben: RAM-Belegung FHEM: 18,5%....

Keine Ahnung was da los ist...

Bitte einmal mit Linux und RAM Belegung beschäftigen. In Deinem Fall wäre wohl der Suchbegriff "Disk caching" hilfreich.
Lass Dir mal mit htop Deinen RAM anzeigen, da wird das ganze etwas besser dargestellt.


[11:20 leon@pi-fhem01 ~] > free -m
             total       used       free     shared    buffers     cached
Mem:           923        804        118         44         39        483
-/+ buffers/cache:        281        641
Swap:           99         48         51


Unter -/+ buffers/cache: sieht man die tatsächliche Auslastung. Und wenn man nun sowas wie "Disk caching" kennt und weiß das RAM eigentlich nie weniger wird wenn man nur die normalen Anzeigen dafür nimmt dann erschrickt man sich auch nicht mehr so schnell.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Bartimaus

@CoolTux

Danke.


                   total       used       free     shared    buffers     cached
Mem:               970        572        397          4         58         242
-/+ buffers/cache: 271        698
Swap:              511          2        509



LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

sku

             total       used       free     shared    buffers     cached
Mem:           927        403        524         57         30        243
-/+ buffers/cache:        129        797
Swap:            0          0          0


fhem.pl hat heute knapp 9% ram belegung, yahoo wetter wars wohl auch nicht... jetzt hab ich sysmon deaktiviert und fhem neu gestartet. wieder 6% ram

Zitat von: CoolTux am 04 September 2017, 11:26:34
Bitte einmal mit Linux und RAM Belegung beschäftigen. In Deinem Fall wäre wohl der Suchbegriff "Disk caching" hilfreich.
Lass Dir mal mit htop Deinen RAM anzeigen, da wird das ganze etwas besser dargestellt.

ich vermute Bartimaus hat die % ram belegung von fhem.pl aus htop? soweit ich weiß, wird disc caching bei dem wert nicht eingerechnet.

Patrik.S

Hallo Boris,

auf Dein Problem eingehend, in der Hoffnung, das ein USB Disconnect vom Kernel vom Rest-System genauso behandelt und erkannt wird, als wenn man von Hand ein USB Device abklemmt.
Du könntest mit einer udev Rule eine Überwachung einbauen und so zumindest einen zwangs reboot erwirken oder noch irgendwelche Diagnosedaten erzeugen und versenden.

Anstatt eine Skipt bein reinstecken zu starten:
https://unix.stackexchange.com/questions/28548/how-to-run-custom-scripts-upon-usb-device-plug-in
kannst Du auch beim Entfernen darauf reagieren:
https://unix.stackexchange.com/questions/178341/udev-rule-action-add-is-working-but-action-remove-isnt-working

Ist natürlich nur eine Symtom Behandlung. Wenn der Hub weg ist, ist er weg, aber das Dateisystem kann mit einem sauberen Reboot besser umgehen als mit einem Reset.
Wenn dein USB Hub aber täglich X mal weg wäre, dann wärst Du natürlich in einer Reboot Loop gefangen
und generell wüstest Du nie, wann der nächste Reboot kommt...  :-\

Bartimaus

Zitat von: sku am 04 September 2017, 20:49:29
ich vermute Bartimaus hat die % ram belegung von fhem.pl aus htop? soweit ich weiß, wird disc caching bei dem wert nicht eingerechnet.

Ja korrekt. Heute morgen hat fhem.pl 19.5% RAM belegt. Ich werde weiter beobachten.
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

Wernieman

Anstatt htop geht auch auch gans normales "ps" ... auch da steht die RAM-Auslastung eines Prozesses ...

z.B. durch:
ps aux | head -1; ps aux | grep fhem
- 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

Dr. Boris Neubert

Hallo Patrik.S,

Zitat von: Patrik.S am 04 September 2017, 20:50:12
kannst Du auch beim Entfernen darauf reagieren:
Ist natürlich nur eine Symtom Behandlung. Wenn der Hub weg ist, ist er weg, aber das Dateisystem kann mit einem sauberen Reboot besser umgehen als mit einem Reset.

das ist ein guter Ansatz. Allerdings wird der Raspi /sbin/reboot nicht mehr ausführen können, wenn die Platte samt darauf befindlichen Dateisystem weg ist.

Ich habe es jetzt (neben der noch ausstehenden Beseitigung der vermutlich technischen Störanfälligkeit) wie folgt eingerichtet:

Der bei mir schon für andere Prüfungen laufende Watchdog prüft alle 120 Sekunden, ob eine Datei auf der Platte geändert wurde:

/etc/watchdog.conf enthält u.a.:
# file
file = /var/run/watchdog_food
change = 120


Der Watchdog wird von Cron gefüttert. /etc/cron/feed_watchdog sieht so aus:
# /etc/cron.d/feed_watchdog
* * * * *       root    /usr/bin/touch /var/run/watchdog_food


Viele Grüße
Boris

Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Bartimaus

#40
Zitat von: Dr. Boris Neubert am 09 September 2017, 18:58:28
Der bei mir schon für andere Prüfungen laufende Watchdog prüft alle 120 Sekunden, ob eine Datei auf der Platte geändert wurde:

Moin,

so habe ich es in etwa auch gelöst, ich überwache meine fhem.save alle 30min.
Das funktioniert prächtig.
Allerdings bin ich da auch mal böse drüber gestolpert, als ich ein KomplettBackup eingespielen musste, welches 2h alt war. Da hing der Banana dank Watchdog in einer Bootschleife...

Ich habe vor 5 Tagen mal ein Komplett-Update-Upgrade+UpdateFHEM gemacht. Nach dem Neustart belegte FHEM 6,5%RAM, heute sind es 8,5%RAM.... scheint sich also etwas gebessert zu haben

LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

RalfRog

Hallo der Beitrag ist ja schon was älter aber mich würde interessieren ob es eine finale Lösung zum "disable"n des USB Ports gibt.

Ich schlage mich auch schon eine ganze Weile damit rum (mein Root-FS läuft auch über eine USB-SSD) und habe mich der der Thematik langsam und schrittweise näher können - es wird ja nichts mehr geloggt.
Zunächst hatte ich Stromversorungs-/Netzteilprobleme im Verdacht, da der Raspi ja bei Unterspannung die USB-LAN Ports abtrennen kann - eine Aufrüstung bei der 5V-Versorgung brachte keine Verbesserung.

Habe dann gestern endlich den Headless-Betrieb aufgegeben und einen Monitor drangehängt.
Siehe da der Effekt konnte nach 20 Versuchen provoziert werden (bei mir ist eine Bügelstation im Nachbarzimmer der Übeltäter).
Es wird genau der Port mit der SSD "disabled" (Tastatur und CUL bleiben eingehängt).
Zitat[98777.938732] usb 1-1-port5: disabled by hub (EMI?), re-enabling...
[98777.938763] usb 1-1.5: USB disconnect, device number 5
Damit sind alle Merkwürdigkeiten erklärbar.

Mal sehen ob die Änderung der USB-Verkabelung Besserung schafft.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

Wernieman

1. Was ist es für eine Bügelstation
2. Wie schaltest Du sie?

Es könnte auch ein Induktiver Stromüberschlag auf dem BUS sein. Hatte dieses mal mit einer SISPM-Dose (welche allerdings dafür bekannt sind)
- 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

Dr. Boris Neubert

@RalfRog: ich bin diesem Problem auch nur auf die Schliche gekommen, nachdem ich das Log mit Remote Syslog auf eine andere Maschine gespiegelt habe, wo ich dann das Abschalten des Ports mit der Platte sehen konnte. Dank Watchdog (siehe Beitrag vom Sep 17) kommt der Raspi aber immer wieder hoch.

Ich weiß nicht, was bei mir die Ursache sein könnte. Werde vielleicht noch Ferrit-Entstörfilter anbringen, wenn ich mal wieder am Raspi vorbeikomme.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

RalfRog

Hallo Zusammen
Trotz zwei Bügelsessions meiner Frau ist es nicht zu einem erneuten Absturz gekommen. Ich hoffe es bleibt dabei - damit war der Austausch des Gehäuses und des USB-Kabels für die SSD hilfreich .

@Dr. Boris Neubert:  ich hole meine Raspi ebenfalls über den Watchdog (Dateiüberwachung) wieder. Das harte Abschalten des USB-Busses im Fehlerfall kann natürlich das Dateisystem beschädigen. Daher war/bin ich auf eine Lösung erpicht.
Ferritkern am Steckernetzteil hatte ich auch schon - half nicht --- 5.2V am Raspi Eingang über ein regelbares Hutschienennetzteil war auch nicht die Lösung.

@Wernimann: Ich schalte die Bügelstion nicht - bzw. ganz normal über den Ein-/Ausschalter und die internen Temperaturschalter. Entfernung zum Raspi 3,50m. Viel Induktion wird das Bügeleisen bzw. die Heizung des Wassertanks nicht haben.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder