Hallo,
mein FHEM läuft auf einem Raspberry Pi 3 unter Raspbian (Debian 8.0). Alle zwei bis drei Wochen hängt sich die Maschine auf.
Folgende Symptome:
- Es wird nichts mehr auf die Platte geschrieben.
- Syslog loggt nicht mehr (ich habe auf rsyslog umgestellt und auf dem Remotehost kommt ab dem Zeitpunkt des Crashs nichts mehr an).
- Kein ssh mehr auf den Rechner möglich (Connection closed).
- FHEM läuft rudimentär weiter. Es wird nichts mehr geloggt und nicht mehr automatisch geschaltet. Es wird aber z.B. noch immer ein neues Bild über RSS an den Browser ausgeliefert. Die darauf angezeigte Uhrzeit geht 2 Stunden nach.
Als Abhilfe habe ich folgendes fest installiert:
- Ich habe ein ausreichend dimensioniertes Netzteil.
- Ich boote von SD-Card und habe / auf einer externen USB-Platte.
Das Problem trat auch vorher schon auf (mit / auf SD-Card).
Ich vermute, dass das Problem mit einem entzogenen Dateisystem zusammen hängt. / ist ext4, /var, /tmp, /opt/fhem, /opt/scratch sind ext4 auf LVM.
Ich suche Anregungen, wie ich dem Problem auf die Schliche kommen kann.
Viele Grüße
Boris
Und wie sehen die letzten 50 Logzeilen aus?
Danke für Deine Antwort.
Ich kann kein Problem im Log erkennen - vielleicht siehst Du etwas im anhängenden Log.
Da steht nichts. Eventuell in der messages zum Zeitpunkt eines Ausfalles. Und dmsg oder so ähnlich wäre noch hilfreich.
Hallo,
das sind die Messages zum Zeitpunkt des Ausfalls. Ich sende alle Nachrichten per rsyslog an den fremden Rechner. Hintergrund ist, dass ich im lokalen Syslog auch schon nichts gesehen hatte und vermutete, dass die interessanten Zeilen nicht mehr geschrieben werden konnten, so dass ich sie nach dem Reboot nicht mehr sehe, und habe daher rsyslog aktiviert. Aber es werden auch keine interessanten Zeilen an den fremden Rechner übertragen.
Ich habe nach dem Crash keine Möglichkeit mehr, auf den Raspi zu kommen, um dmesg auszuführen oder zu analysieren, woran es hängt. Ich muss den Reset-Knopf drücken.
Bitte frage weiter! Vielleicht übersehe ich einen Kniff, doch noch mehr Informationen zu sammeln.
Viele Grüße
Boris
Wie gesagt es gibt noch die /var/log/messages eventuell steht da was. Ansonsten wäre so ein Verhalten Richtung Speicher oder Storage zu suchen.
Pro forma Mal die SD Karte tauschen.
Was genau hat es mit dem LVM auf sich? Aber da würde ja wenn gleich nach dem boot was kommen und nicht erst nach Tagen.
Vielleicht läuft auch was voll.
Klingt ähnlich wie hier (https://forum.fhem.de/index.php/topic,61206.0.html), wobei Sonderfall USB-Stick anstatt SD-Card.
Hab nach wie vor keine Lösung u. erkläre es mir nach wie vor mit "USB-Problemen".
Good luck
Markus
Freies Spekulieren ist ja wohl erlaubt hier....
Für mich wäre der Ansatzpunkt, dass eigentlich nichts mehr geht (inklusive syslog), aber trotzdem per RSS noch etwas geliefert wird und FHEM rudimentär weiterläuft. Das passt mit dem restlichen Verhalten nicht zusammen.
Wenn es die Filesysteme sind, wäre ja vielleicht ein dumpen alle 5 Sekunden der Ausgabe von df (oder ähnliches) in ein Verzeichnis auf der SD hilfreich?
Alternativ auch mal Ausgaben von top?
Passiert das auch ohne laufendes FHEM?
Wie gesagt alles Spekulation...
Also scheinbar laufen alle Programme im Speicher weiter, das hört sich nach io-Problemen an, also SDCard bzw. bei Dir USB-Stick / USB-Probleme.
Bei einem Rechner würde ich auch die Festplattencontroller prüfen, nur beim Pi .....
Kannst Du ins Netzwerk loggen? z.b. haben viele NAS die Möglichkeiten, einen Logserver aufzusetzen, oder einen 2. Rechner ...
Weiß jetzt aktuell nicht beim Pi, wie ist eigentlich die SDCard angeschlossen?
Hallo,
wie gesagt, ich logge per rsyslog alles, was in irgendwelche Logs ins /var/log verstreuselt wird, in eine Log-Datei auf einem Remote Host. Das ist soweit also vollständig.
Das Problem trat früher auf, als ich nur eine SD-Karte hatte für Boot und Root und auch jetzt, wo Root und weitere Verzeichnisse auf einer externen USB-Platte (nicht Stick) liegen (SD-Karte wird daher nach dem Booten nicht mehr angesprochen). Auf allen Verzeichnissen (außer /boot) sind noch mehrere bis mehrere hundert GB frei. Es liegt m.E. daher weder an SD-Karte noch an Platte.
Ob es ohne laufendes FHEM auch geschieht, weiß ich nicht, weil ich das nur testen kann, indem ich meine Hausautomation solange auf einen zweiten Rechner verschiebe.
Ich befürchte, dass ich einen eigenen Prozess schreiben muss, der Daten sammelt und periodisch auf einen anderen Rechner schubst, und hoffen, dass das Schubsen nach dem Crash noch funktioniert (so wie der Zugriff auf den in FHEM eingebauten Webserver, der mir nach dem Crash per RSS noch die Uhrzeit und Bilder ausliefert, aber ansonsten nicht mehr reagiert).
Ich tippe im Moment entweder auf eine Störung im Zugriff auf das Filesystem (die per RSS ausgelieferten Bilder könnten im Cache liegen) oder eine Störung im TCP/IP-Stack (und nur die bestehende TCP-Verbindung für RSS bleibt am Leben).
Viele Grüße
Boris
Ich habe nicht gesagt, das es am frreien Platz liegt, sondern am IO-System. Deine Folgende Aussage zieht eigentlich auf das gleiche:
Zitat... Zugriff auf das Filesystem ...
Wie schon gefragt: Kannst Du das Filesystem prüfen?
Zitat von: Wernieman am 28 August 2017, 08:02:35
Wie schon gefragt: Kannst Du das Filesystem prüfen?
Ich kann heute abend nochmal explizit fsck laufen lassen und sehen, was gemeldet wird. fsck prüft und reparierte nach dem letzten Reset beim Booten automatisch, weil durch das Filesystem ja wegen des harten Abbruchs durch den Reset unclean war.
Nach einem Crash und vor einem Reboot sind meine Möglichkeiten begrenzt, weil ich nicht mehr auf den Raspi komme. Ich könnte alle 5 Minuten prüfen, ob man noch schreiben kann, und im Fehlerfall fsck auslösen und das Protokoll verschicken. Ich zweifele aber daran, dass das noch funktioniert, weil vermutlich nicht einmal mehr vom Filesystem gelesen werden kann, um fsck auszuführen.
Gibt es noch Vorschläge für weitere Werkzeuge zur Prüfung des Filesystems?
Grüße
Boris
Du sagtest, das die Logfiles auf einen anderen Server geschickt werden ... hast Du das Kernlog? bzw. kannst Du dort nach "i/o" greppen?
Werden eventuell viele kleine Dateien z.B. nach /tmp oder /var/tmp geschrieben, die bis zum Reboot nicht mehr gelöscht werden? Eventuell gehen Dir dann die Inodes aus, obwohl noch massig Platz da ist. Was sagt denn df -i?
Zitat von: mahowi am 28 August 2017, 12:37:01
Werden eventuell viele kleine Dateien z.B. nach /tmp oder /var/tmp geschrieben, die bis zum Reboot nicht mehr gelöscht werden? Eventuell gehen Dir dann die Inodes aus, obwohl noch massig Platz da ist. Was sagt denn df -i?
Das ist auf jeden Fall ein interessanter Aspekt. Schreibt FHEM solche vielen kleinen Dateien oder was macht das am ehesten?
Wie ich bisher gelesen habe, kann man die Inodes-Anzahl nur beim Formatieren einer Partition ändern. Das führt zu einigem Ärger in Bezug auf den Raspberry Pi, da hier gewöhnlich keine Partitionen formatiert werden, sondern diese direkt aus einem Image kommen, welches auf die SD-Karte geklont wird.
Jetzt ist die Frage, wie /tmp und /var/tmp eingehängt sind und wo sie physikalisch liegen...und welche Werte dafür gelten.
Am einfachsten könnte man wohl einen Aufräumprozess implementieren, um alte Dateien zu löschen...
Was bringt denn die Ausgabe von lsof?
sudo apt-get install lsof
Nach einem frischen Systemstart, wenn alles oben ist und läuft ein
lsof > lsof_fresh.txt
Einige Stunden oder Tage später nochmal einen Abzug machen
lsof > lsof_1TageSpaeter.txt
und die Anzahl der offenen Dateien vergleichen.
wc -l lsof_fresh.txt
wc -l lsof_xTageSpaeter.txt
Die Anzahl darf jetzt nicht explodieren.
Weitere Detailanalysen kann man dann wie hier beschrieben machen
https://www.ibm.com/developerworks/aix/library/au-lsof.html (https://www.ibm.com/developerworks/aix/library/au-lsof.html)
Gibt es einen Prozess der aus der Reihe tanzt? Den dann genauer ansehen.
Ich hatte schon mal eine Software, die den TCP Stack aufgefressen hatte.
Es konnten keine weiteren neuen Verbindungen aufgebaut werden.
lsof | grep IPv4
Auch sehr beliebt, immer eine Datei öffnen, diese dann aber nicht schließen, weil man glaubt in der Programiersprache/Skript Spache muss man das nicht explizit machen und schon sammelt sich was an über die Tage, wenn es ein Dienst ist.
mir fällt auf, dass "gegen ende" die einträge zu avahi-daemon fehlen. zu beginn sind abwechselnd avahi-daemon und dhcpd einträge. meine erste vermutung währe, dass LAN abschmiert. kannst du einen monitor anschliessen und live mitschauen? zb "watch ifconfig"
ansonsten tippe ich auf vollen ram oder eine angeschlossene hw. oder der pi selbst, schon mal einen anderen versucht?
war bei / auf sd und hdd immer die selbe hw angeschlossen?
Wieviele IP Adressen gedenkt dein RPi zu haben?
Ein ifconfig -a muss das nicht unbedingt anzeigen, daher gleich ein ip addr
Ich hatte mal eine statische IP vergeben, aber der DHCP Client war noch aktiv und der hat sich trotzdem irgendwann eine Fantasie IP geholt (woher auch immer, ein Router mit DHCP Server ist in dem Netz nicht vorhanden gewesen).
-----------------------
Mir ist das Zauberzeugs mit einem Lokalen Netz via avahi Suspekt, aber egal.
"Invalid response packet from host ...." --> Ist das zufällig ein Windows 10 Rechner und der war dann später nicht mehr an? (und darum fehlen dann die Einträge im Log?)
Seit 2014 gibt es einen Bugeintrag https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1342400 (https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1342400) zu diesem Warning "Invalid response packet from host ...."
und erst letztes Jahr 2016 wurde nun endlich ein Fix eingebracht. Hauptsächlich Windows 10 Rechner erzeugen wohl diesen Eintrag.
Der avahi-daemon im Rasperian nutzt ja eine ältere Version 0.6.32-5 von 2015 http://metadata.ftp-master.debian.org/changelogs/main/a/avahi/avahi_0.6.31-5_changelog (http://metadata.ftp-master.debian.org/changelogs/main/a/avahi/avahi_0.6.31-5_changelog)
Der RPi bräuchte also eine Version 0.6.32 oder 0.6.31-6 oder wie man die hier nummeriert.
Aber das behebt ja nicht dein Problem, sondern macht nur das Logfile sauberer und wir hätten nie gesehen das Du dein lokales Netz mit avahi aufspannst?!?
Hallo,
auf meinem System habe ich gestern gemerkt (htop), das FHEM im RAM (970MB) 60% belegt hat. Zu diesem Zeitpunkt lief das Sytem 55 Tage ohne Probleme.
Als ich dann noch ein umfangreiches Logfile aufrufen wollte, um mir den RAM-Auslastungsverlauf anzuzeigen (sysmon), ist FHEM abgestürzt. Nach einem Neustart von FHEM war die RAM-Belegung durch FHEM bei 10%.
Hat jemand ähnliches beobachtet ?
Ich hatte ein ähnliches Problem wie der Threadersteller. Alle 3 Wochen hing sich das System komplett auf. Die LEDs blinkten lustig vor sich hin, aber der Rechner war noch nichtmal mehr per ping erreichbar.
Habe dann den Banana komplett neu und "sauber" aufgesetzt, seitdem ToiToiToi. Sollte sich das System aufhängen, aktiviert sich der HardwareWatchdog und startet den Rechner komplett neu.
das habe ich auch schon länger beobachtet, aber erst 1-2 mal auswirkungen gemerkt. ich jetzt mal meine zabbix statistiken angeschaut, screenshots im anhang.
wenn der freie ram wieder oben ist, wurde neu gestartet (komplettes OS oder nur fhem)
in htop geht auch die ram belegung von fhem rauf, es ist also nichts anderes schuld am aussehen der screenshots.
ursachenforschung hab ich mal betrieben als ich auswirkungen gemerkt hab, damals wurde ein bash script oft aufgerufen und nicht beendet, die prozesse waren in htop zu sehen. das war aber nur damals der fall, jetzt sind keine unüblichen prozesse mehr zu sehen.
Da waähre es gut zu wissen, welche Module Du verwendest .. sieht mir nach einem heftigen MemoryLeak aus ..
ich habe eben alle 3 fhems upgedated, damit sie am selben stand sind. eine kurze suche nach memory leak ergab, dass einer presence verdächtigte. ich verwende auf allen 3 instanzen presence mit SNMP abfrage, habe jetzt testweise am rasp3 die presence devices deaktiviert (mit attr disable 1).
ich will aber den thread nicht für memoryleaks missbrauchen, sollen wir das thema wo anders weiter verfolgen?
ich vermute, fheminfo ist der richtige befehl? hier die ergebnisse:
vm_fhem:
System Info
ConfigType: configFile
SVN rev: 14980
OS: linux
Perl: 5.20.2
uniqueId: ...
Modules Model Count
AMADCommBridge 1
AMADDevice 1
Astro 1
CALVIEW 1
Calendar 1
DbLog
MYSQL 2
DbRep 1
FHEM2FHEM 3
FHEMWEB 1
FileLog 45
GEOFANCY 1
HOMEMODE 1
HTTPSRV 3
HourCounter 1
NUT 1
PRESENCE
function 4
RESIDENTS 1
RFHEM 3
ROOMMATE 2
RSS 2
SVG 21
SYSMON 1
TRAFFIC 2
Twilight 1
UWZ 1
WOL 1
Weather 1
Wunderground 1
XBMC 1
allowed 2
at 3
autocreate 1
cloneDummy 18
dewpoint 1
dummy 30
gcmsend 2
notify 19
readingsGroup 7
remotecontrol 3
telnet 1
watchdog 2
webViewControl 1
weblink 10
rasp1:
System Info
ConfigType: configFile
SVN rev: 14980
OS: linux
Perl: 5.20.2
uniqueId: ...
Modules Model Count
FHEM2FHEM 2
FHEMWEB 1
FileLog 1
PRESENCE
function 2
RESIDENTS 1
RFHEM 2
ROOMMATE 2
SYSMON 1
Twilight 1
WOL 1
Weather 1
allowed 2
autocreate 1
dewpoint 1
dummy 7
eventTypes 1
harmony 9
notify 17
readingsGroup 1
telnet 1
watchdog 2
weblink 3
rasp3:
System Info
ConfigType: configFile
SVN rev: 14980
OS: linux
Perl: 5.20.2
uniqueId: 77e...
Modules Model Count
CALVIEW 1
CUL_HM
HM-ES-PMSw1-Pl 1
ActionDetector 1
HM-TC-IT-WM-W-EU 4
CCU-FHEM 1
HM-CC-RT-DN 4
Calendar 1
DbLog
MYSQL 1
DbRep 1
FHEM2FHEM 2
FHEMWEB 1
FileLog 1
HMLAN 1
HMinfo 1
NUT 1
PRESENCE
function 2
RESIDENTS 1
RFHEM 2
ROOMMATE 2
SVG 1
SYSMON 1
Twilight 1
Weather 1
allowed 2
at 4
autocreate 1
dewpoint 1
dummy 19
eventTypes 1
gcmsend 2
notify 22
readingsGroup 5
telnet 1
watchdog 2
weblink 3
Hi
das wär ja nen Ding. Ich hatte auch bis vor kurzem (also über einen Zeitraum von ca. 6 Monaten und länger) probleme mit wenig freiem Speicher. Fhem ist dann immer abgeschmiert und ich konnte entweder fhem neu starten oder den raspi. Ich verwende auch presence (2x Bluethooth IPhone) + (2x IPhone MAC Fritzboxen).
Seltsamerweise ist dieses Problem seit ca. 4 Wochen nicht mehr aufgetreten. Ich konnte die Ursache allerdings auch nie richtig lokalisieren, aber der Beginn mag in etwa mit dem Betrieb von Presence übereinstimmen.
Gruß Michael
Presence wird auch hier erwähnt: https://forum.fhem.de/index.php/topic,76002.0.html
Ich nutze Presence nicht, und mein Raspi mit fhem (ich glaube es ist ein 2er) läuft schon eine gefühlte ewigkeit. (viel machen tut er aber auch momentan nicht ;) )
hab eben entdeckt, dass bei meinen raspi3 und raspi1 die firmwareupdates nicht aktiv waren. hab das nachgeholt:
/etc/apt/sources.list firmware dazuschreiben:
deb http://mirrordirector.raspbian.org/raspbian/ jessie main firmware contrib non-free rpi
danach
apt-get update
apt-get upgrade
rpi-update
vll. vor rpi-update rebooten. ich habs nicht gemacht, da beim upgrade nicht viel gemacht wurde (vorallem kein kernel upgrade, da hätt ich rebootet)
@pah vll behebt das deine instabilität? oder vll kommt dadurch jetzt bei mir instabilität :-[
zum memory leak: neuer screenshot im anhang, in den paar stunden wurden 16mb ram mehr belegt. jedoch hab ich diesmal nicht per htop kontrolliert, ob fhem schuld ist... ich gehe aber davon aus.
fhem.pl hatte gestern laut htop ca. 8% belegung, heute sind es schon 10%
habe nun presence wieder aktiviert.
als nächstes ist yahoo wetter dran. ist nun deaktiviert, fhem neu gestartet, 6% ram nutzung.
Hallo,
ich hatte heute gerade das volle Programm an Updates durchexerziert (FHEM, Raspian, Firmware) und war dabei, ein Skript zu schreiben, das über eine permanente Socketverbindung per netcat alle Stunde die Informationen über offene Files und Sockets, Speicherbelegung, Plattplatz und Inodes an einen externen Rechner senden sollte, als es passiert ist: Dateisystem futsch, keine Befehle mehr ausführbar, nur noch Reset half.
Ich habe aber dieses Mal ein aussagekräftiges Log:
2017-09-03T14:17:50+02:00 has kernel: [ 1114.230715] usb 1-1-port5: disabled by hub (EMI?), re-enabling...
2017-09-03T14:17:50+02:00 has kernel: [ 1114.230758] usb 1-1.5: USB disconnect, device number 4
2017-09-03T14:17:50+02:00 has kernel: [ 1114.230765] usb 1-1.5.3: USB disconnect, device number 5
2017-09-03T14:17:50+02:00 has kernel: [ 1114.231139] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
2017-09-03T14:17:50+02:00 has kernel: [ 1114.231158] ftdi_sio 1-1.5.3:1.0: device disconnected
2017-09-03T14:17:50+02:00 has kernel: [ 1114.231372] pl2303 ttyUSB1: pl2303_read_int_callback - usb_submit_urb failed with result -19
2017-09-03T14:17:50+02:00 has kernel: [ 1114.233599] usb 1-1.5.4: USB disconnect, device number 6
2017-09-03T14:17:50+02:00 has systemd[1]: Stopping LVM2 PV scan on device 8:4...
2017-09-03T14:17:50+02:00 has systemd[1]: Stopped LVM2 PV scan on device 8:4.
2017-09-03T14:17:50+02:00 has systemd[1]: Stopping Swap.
2017-09-03T14:17:50+02:00 has systemd[1]: Stopped target Swap.
2017-09-03T14:17:50+02:00 has systemd[1]: Deactivating swap /dev/disk/by-id/usb-WD_Elements_25A2_575847314131373133434E41-0:0-part3...
2017-09-03T14:17:50+02:00 has systemd[1]: Deactivating swap /dev/disk/by-partuuid/0c1b81cb-03...
2017-09-03T14:17:50+02:00 has systemd[1]: Deactivating swap /dev/disk/by-path/platform-3f980000.usb-usb-0:1.5.4:1.0-scsi-0:0:0:0-part3...
2017-09-03T14:17:50+02:00 has systemd[2045]: Failed at step EXEC spawning /sbin/swapoff: Input/output error
2017-09-03T14:17:50+02:00 has systemd[1]: Deactivating swap /dev/disk/by-uuid/1af2bdf0-0409-43ef-af91-b88522092051...
2017-09-03T14:17:50+02:00 has systemd[1]: Deactivating swap /dev/sda3...
2017-09-03T14:17:50+02:00 has systemd[1]: dev-disk-by\x2did-usb\x2dWD_Elements_25A2_575847314131373133434E41\x2d0:0\x2dpart3.swap swap process exited, code=exited status=203
2017-09-03T14:17:50+02:00 has systemd[1]: Deactivated swap /dev/disk/by-id/usb-WD_Elements_25A2_575847314131373133434E41-0:0-part3.
2017-09-03T14:17:50+02:00 has systemd[1]: Unit dev-disk-by\x2did-usb\x2dWD_Elements_25A2_575847314131373133434E41\x2d0:0\x2dpart3.swap entered failed state.
Störung am externen 7-Port-USB-Hub, der Kernel schmeisst das Hub raus, am Hub hängt aber auch die Festplatte, sag zum Abschied leise Servus :(
Am Hub hängen die Festplatte (750 GB WD Elements), ein Arduino Pro (PL2303) und ein Denkovi-1wire-Busmaster (FTDI). Ich muss sehen, ob der Arduino Pro oder der 1wire-Busmaster an Port 5 hängen, und die Störung verursacht haben. Nächstes Wochenende steht dann wohl im Zeichen der elektromagnetischen Verträglichmachung der Installation (USB-Kabel durch bessere Kabel ersetzen, Ferritkerne aufstecken, ...).
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 27 August 2017, 13:05:15
Das Problem trat auch vorher schon auf (mit / auf SD-Card).
war damals swap auf der hdd, oder irgendwas anderes wichtiges? sonst hätte der pi nicht abschmieren dürfen, wenn der hub weg ist.
wieso verwendest du swap am pi? das ist mir nicht ganz klar.
Gegenfrage: Warum nicht?
mein hauptgrund ist, um die schreibvorgänge der sd karte zu minimieren. und wie am memoryverlauf von mir zu sehen, wurden max. 50% ram belegt und da ging wohl irgendwas schief. von daher ist swap auch nicht notwendig.
bei mir ist nur eine sd karte verbaut, /var/log und /tmp sind als tmpfs gemounted. root schaut in meiner fstab so aus:
/dev/mmcblk0p2 / ext4 defaults,noatime,commit=120 0 1
kurze kopierte erklärung:
The noatime option fully disables writing file access times to the drive every time you read a file.
commit=nrsec
Sync all data and metadata every nrsec seconds.
logging macht mein 24/7 PC, der hat alle hdds/ssds dafür verbaut.
der nachteil des single point of failure ist mir klar, aber dann fehlt halt mal was... wobei dblog in fhem mittlerweile zwischenspeichert, das ist also auch kein problem.
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 ...
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...
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.
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.
@CoolTux
Danke.
total used free shared buffers cached
Mem: 970 572 397 4 58 242
-/+ buffers/cache: 271 698
Swap: 511 2 509
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.
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 (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 (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... :-\
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.
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
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 = 120Der 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
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
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.
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)
@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.
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.
8 Monate später....
kein Absturz mehr bzw. weghängen des USB-Ports :) :)
Also manchmal liegt es nur am Anschlusskabel / Gehäuse - Controller
Ich weiss, ich bin etwas spät, aber:
Für's debuggen von Raspis, die die Netzwerkschnittstelle abdrehen oder ähnliches habe ich immer eine GPIO-USB serielle Schnittstelle genutzt. Einfach und praktisch (wenn man eine da hat). :-)
Nur zur Sicherheit, weil ich beim NAS-Aufbau mit Pi 3B darüber gestolpert bin und das hier im Thread noch nicht gesehen habe:
Ohne besondere Einstellung schaltet der Raspberry Pi ab einer Stromentnahme von 600 mA die USB-Ports komplett ab. Die Grenze gilt nicht pro Port, sondern insgesamt! Damit ist sie ohne powered USB-Hub auch schnell erreicht.
Somit ist das auch meist keine Frage einer "besseren" 5V Versorgung, da hart nach Messwert gekappt wird!
Man kann über die config.txt das Limit auf 1.2A hochsetzen:
https://www.elektronik-kompendium.de/sites/raspberry-pi/2206111.htm (https://www.elektronik-kompendium.de/sites/raspberry-pi/2206111.htm)
Hallo,
bei mir musste ich einen kontinuierlichen Speicherverbrauch feststellen, ohne einen Anhaltspunkt zu finden welches Modul es ist.
Es hat nichts mit dem Betriebssystem zu tun (ich habe von Stretch auf Buster hochgerüstet, keine Verbesserung obwohl in der Perl Version 5.24 ein Speicher leak sein sollte).
Mein Watchdog ist ein DOIF was bei einem Speicherverbrauch von >24% FHEM einmal in der Nacht neu startet.
Ich wäre interessiert, dass Pflaster abzunehmen und den Fehler zubeseitigen, hat jemand eine Idee wie man in FHEM den Speicherverbrauch der einzelnen Module loggen kann bzw. jeder andere Gedanke der zu einer Lösung führen kann?
Gruß Osid-timo
Hallo osid-timo,
hier hast Du Dich sicher schon informiert: https://forum.fhem.de/index.php?topic=84372.0
Grüße Jörg
Gesendet von iPhone mit Tapatalk
Hallo Jörg,
den Link kenne ich, ja habe ich mich nochmals durchgearbeitet
und auch die neueste Version bringt bei mir keine Verbesserung?
Gruß Osid-timo