Mihome Vacuum Karte
-
ich hab leider nach meinem Update auf 3.5.0 auch die genannten Probleme.
host.haustuerpi 2022-07-07 00:13:21.550 info instance system.adapter.mihome-vacuum.0 terminated with code NaN () host.haustuerpi 2022-07-07 00:13:21.550 warn instance system.adapter.mihome-vacuum.0 terminated due to SIGABRT host.haustuerpi 2022-07-07 00:13:21.549 error Caught by controller[0]: corrupted double-linked list mihome-vacuum.0 2022-07-07 00:13:13.007 warn Error at history: MESSAGE TIMEOUT mihome-vacuum.0 2022-07-07 00:13:10.352 info Room array empty... generate from mapdata.. [[17,"room17"],[21,"room21"],[20,"room20"],[19,"room19"],[16,"room16"],[22,"room22"],[18,"room18"],[23,"room23"],[1,"room1"]]dazu sei aber gesagt, dass ich gerade diverse Probleme mit meinem Multihostsystem hab, nachdem ich alles mal auf den neuesten Stand bringen wollte (Linux, npm, js-controller, etc) - ich weiß, never change a running... hab glaube ich so alles falsch gemacht, was geht... :-(
Außerdem habe ich das Problem, dass der Host, auf dem der Adapter läuft, sich jeden Tag komplett wegschießt, weil die log dateien syslog und kern-log auf insg 22GB anwachsen und das Filesystem damit vollgelaufen ist. Diese lösche ich dann immer von Hand und starte das System neu. Wenn ich den Adapter deaktiviere, passiert dies nicht. Ich schließe als Ursache aber natürlich meine Skripte, die auf dem Adapter laufen, nicht aus - die interagieren viel mit dem "cleanSegments" Befehl (habe sie aber seit das System so Probleme macht meines Wissens nicht mehr genutzt).
vielleicht hat ja jemand eine Idee, ein ähnliches Problem, oder ich kann irgendwie mit logs o.ä. helfen ein Problem zu lösen (falls es nicht hier vor dem Rechner sitzt). VG
-
ich hab leider nach meinem Update auf 3.5.0 auch die genannten Probleme.
host.haustuerpi 2022-07-07 00:13:21.550 info instance system.adapter.mihome-vacuum.0 terminated with code NaN () host.haustuerpi 2022-07-07 00:13:21.550 warn instance system.adapter.mihome-vacuum.0 terminated due to SIGABRT host.haustuerpi 2022-07-07 00:13:21.549 error Caught by controller[0]: corrupted double-linked list mihome-vacuum.0 2022-07-07 00:13:13.007 warn Error at history: MESSAGE TIMEOUT mihome-vacuum.0 2022-07-07 00:13:10.352 info Room array empty... generate from mapdata.. [[17,"room17"],[21,"room21"],[20,"room20"],[19,"room19"],[16,"room16"],[22,"room22"],[18,"room18"],[23,"room23"],[1,"room1"]]dazu sei aber gesagt, dass ich gerade diverse Probleme mit meinem Multihostsystem hab, nachdem ich alles mal auf den neuesten Stand bringen wollte (Linux, npm, js-controller, etc) - ich weiß, never change a running... hab glaube ich so alles falsch gemacht, was geht... :-(
Außerdem habe ich das Problem, dass der Host, auf dem der Adapter läuft, sich jeden Tag komplett wegschießt, weil die log dateien syslog und kern-log auf insg 22GB anwachsen und das Filesystem damit vollgelaufen ist. Diese lösche ich dann immer von Hand und starte das System neu. Wenn ich den Adapter deaktiviere, passiert dies nicht. Ich schließe als Ursache aber natürlich meine Skripte, die auf dem Adapter laufen, nicht aus - die interagieren viel mit dem "cleanSegments" Befehl (habe sie aber seit das System so Probleme macht meines Wissens nicht mehr genutzt).
vielleicht hat ja jemand eine Idee, ein ähnliches Problem, oder ich kann irgendwie mit logs o.ä. helfen ein Problem zu lösen (falls es nicht hier vor dem Rechner sitzt). VG
@tobitobsta sagte in Mihome Vacuum Karte:
ich weiß, never change a running...
Quatsch im Quadrat.
Man muss die 'changes' nur richtig machen. -
ich hab leider nach meinem Update auf 3.5.0 auch die genannten Probleme.
host.haustuerpi 2022-07-07 00:13:21.550 info instance system.adapter.mihome-vacuum.0 terminated with code NaN () host.haustuerpi 2022-07-07 00:13:21.550 warn instance system.adapter.mihome-vacuum.0 terminated due to SIGABRT host.haustuerpi 2022-07-07 00:13:21.549 error Caught by controller[0]: corrupted double-linked list mihome-vacuum.0 2022-07-07 00:13:13.007 warn Error at history: MESSAGE TIMEOUT mihome-vacuum.0 2022-07-07 00:13:10.352 info Room array empty... generate from mapdata.. [[17,"room17"],[21,"room21"],[20,"room20"],[19,"room19"],[16,"room16"],[22,"room22"],[18,"room18"],[23,"room23"],[1,"room1"]]dazu sei aber gesagt, dass ich gerade diverse Probleme mit meinem Multihostsystem hab, nachdem ich alles mal auf den neuesten Stand bringen wollte (Linux, npm, js-controller, etc) - ich weiß, never change a running... hab glaube ich so alles falsch gemacht, was geht... :-(
Außerdem habe ich das Problem, dass der Host, auf dem der Adapter läuft, sich jeden Tag komplett wegschießt, weil die log dateien syslog und kern-log auf insg 22GB anwachsen und das Filesystem damit vollgelaufen ist. Diese lösche ich dann immer von Hand und starte das System neu. Wenn ich den Adapter deaktiviere, passiert dies nicht. Ich schließe als Ursache aber natürlich meine Skripte, die auf dem Adapter laufen, nicht aus - die interagieren viel mit dem "cleanSegments" Befehl (habe sie aber seit das System so Probleme macht meines Wissens nicht mehr genutzt).
vielleicht hat ja jemand eine Idee, ein ähnliches Problem, oder ich kann irgendwie mit logs o.ä. helfen ein Problem zu lösen (falls es nicht hier vor dem Rechner sitzt). VG
@tobitobsta sagte in Mihome Vacuum Karte:
weil die log dateien syslog und kern-log auf insg 22GB anwachsen
Dann solltest du die Ursache angehen.
Was wird denn in den 22GB so verewigt? -
@tobitobsta sagte in Mihome Vacuum Karte:
ich weiß, never change a running...
Quatsch im Quadrat.
Man muss die 'changes' nur richtig machen.@thomas-braun said in Mihome Vacuum Karte:
@tobitobsta sagte in Mihome Vacuum Karte:
ich weiß, never change a running...
Quatsch im Quadrat.
Man muss die 'changes' nur richtig machen.... okay - danke, das beruhigt mich. Hatte mich an die Anleitungen gehalten.
@thomas-braun said in Mihome Vacuum Karte:
Dann solltest du die Ursache angehen.
Was wird denn in den 22GB so verewigt?... da gehts schon los: "tail" gab nicht so wirklich was (für mich) aussagekräftiges, weil es auch immer irgendwie was anderes war. Dann bin ich leider schon gescheitert die logs mal auf meinen PC zu ziehen, da ich (Linux noob) auf dem Pi die 11GB Dateien aufm Linux nicht gescheit analysieren oder anschauen kann. Hast Du evtl eine Idee?
-
@thomas-braun said in Mihome Vacuum Karte:
@tobitobsta sagte in Mihome Vacuum Karte:
ich weiß, never change a running...
Quatsch im Quadrat.
Man muss die 'changes' nur richtig machen.... okay - danke, das beruhigt mich. Hatte mich an die Anleitungen gehalten.
@thomas-braun said in Mihome Vacuum Karte:
Dann solltest du die Ursache angehen.
Was wird denn in den 22GB so verewigt?... da gehts schon los: "tail" gab nicht so wirklich was (für mich) aussagekräftiges, weil es auch immer irgendwie was anderes war. Dann bin ich leider schon gescheitert die logs mal auf meinen PC zu ziehen, da ich (Linux noob) auf dem Pi die 11GB Dateien aufm Linux nicht gescheit analysieren oder anschauen kann. Hast Du evtl eine Idee?
11GB Klopper sind halt schwer zu handeln. Das passt in den Speicher ja nicht rein.
Was kommt denn im tail immer dazu? Das muss ja rappeln, dass da GBweise Text zusammen kommt. -
11GB Klopper sind halt schwer zu handeln. Das passt in den Speicher ja nicht rein.
Was kommt denn im tail immer dazu? Das muss ja rappeln, dass da GBweise Text zusammen kommt.@thomas-braun
gerade neu loslaufen lassen und den Adapter mal wieder angestellt - es sieht aber so aus als wenn die logs dann ab irgendwann schlagartig volllaufen und nicht ständig ein bisschen. hier mal ein copy/paste vom jetztigen satatus: -
11GB Klopper sind halt schwer zu handeln. Das passt in den Speicher ja nicht rein.
Was kommt denn im tail immer dazu? Das muss ja rappeln, dass da GBweise Text zusammen kommt.also nun passiert hier was
iobroker log zeigt immer wieder das hier:
... aber evtl ist es ja ein Folgefehler aufgrund des übergelaufenen Filesystems....ich konnte aber mit less an die Stelle im syslog scrollen wo es meiner Meinung nach interessant wird:
Jul 7 19:08:39 haustuerpi bash[475]: munmap_chunk(): invalid pointer Jul 7 19:08:50 haustuerpi kernel: [29526.174369] device eth0 entered promiscuous mode Jul 7 19:08:56 haustuerpi kernel: [29532.033920] device eth0 left promiscuous mode Jul 7 19:09:01 haustuerpi CRON[13730]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi) Jul 7 19:09:18 haustuerpi bash[475]: cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: Keine Berechtigung Jul 7 19:09:18 haustuerpi bash[475]: cat: /sys/class/net/wlan0/statistics/rx_bytes: Datei oder Verzeichnis nicht gefunden Jul 7 19:09:18 haustuerpi bash[475]: cat: /sys/class/net/wlan0/statistics/tx_bytes: Datei oder Verzeichnis nicht gefunden Jul 7 19:09:20 haustuerpi systemd[1]: Starting Clean php session files... Jul 7 19:09:21 haustuerpi systemd[1]: phpsessionclean.service: Succeeded. Jul 7 19:09:21 haustuerpi systemd[1]: Started Clean php session files. Jul 7 19:09:24 haustuerpi bash[475]: # Jul 7 19:09:24 haustuerpi bash[475]: # Fatal error in , line 0 Jul 7 19:09:24 haustuerpi bash[475]: # Check failed: !backing_store->is_wasm_memory(). Jul 7 19:09:24 haustuerpi bash[475]: # Jul 7 19:09:24 haustuerpi bash[475]: # Jul 7 19:09:24 haustuerpi bash[475]: # Jul 7 19:09:24 haustuerpi bash[475]: #FailureMessage Object: 0xbe8323a0 Jul 7 19:09:24 haustuerpi kernel: [29560.437554] Unhandled prefetch abort: breakpoint debug exception (0x222) at 0x00000000 Jul 7 19:09:24 haustuerpi kernel: [29560.437656] Unhandled prefetch abort: breakpoint debug exception (0x222) at 0x00000000 Jul 7 19:09:24 haustuerpi kernel: [29560.437695] Unhandled prefetch abort: breakpoint debug exception (0x222) at 0x00000000 Jul 7 19:09:24 haustuerpi kernel: [29560.437732] Unhandled prefetch abort: breakpoint debug exception (0x222) at 0x00000000 Jul 7 19:09:24 haustuerpi kernel: [29560.437768] Unhandled prefetch abort: breakpoint debug exception (0x222) at 0x00000000 Jul 7 19:09:24 haustuerpi kernel: [29560.437805] Unhandled prefetch abort: breakpoint debug exception (0x222) at 0x00000000 Jul 7 19:09:24 haustuerpi kernel: [29560.437841] Unhandled prefetch abort: breakpoint debug exception (0x222) at 0x00000000... und das zieht er dann durch bis um ca 22:05 scheinbar die Platte voll war.... das ist Zeitlich auch passend zum iobroker log.
-
@tobitobsta sagte in Mihome Vacuum Karte:
https://forum.iobroker.net/topic/54012/iobroker-kernel-unhandled-prefetch-abort-breakpoint-debug
Hier auch der mihome-vacuum.
Mach mal ein issue auf. Auch wenn das vermutlich schwer sein wird da zu debuggen. -
@tobitobsta sagte in Mihome Vacuum Karte:
https://forum.iobroker.net/topic/54012/iobroker-kernel-unhandled-prefetch-abort-breakpoint-debug
Hier auch der mihome-vacuum.
Mach mal ein issue auf. Auch wenn das vermutlich schwer sein wird da zu debuggen.@thomas-braun said in Mihome Vacuum Karte:
Mach mal ein issue auf. Auch wenn das vermutlich schwer sein wird da zu debuggen.
unschuldige meine Unwissenheit: wo soll ich ein issue aufmachen?
VG -
-
-
@thomas-braun Macht meiner Meinung nach keinen Sinn. Das wird dann die canvas lib sein, die muß wahrscheinlich neu gebildet werden. Die macht öfter Probleme. Da hilf ggf. die Karte auszuschalten.
@dirkhe sagte in Mihome Vacuum Karte:
Das wird dann die canvas lib sein, die muß wahrscheinlich neu gebildet werden.
Möglich. Aber die sollte eigentlich den Kernel kalt lassen.
Wie schaut denn canvas aus?
cd /opt/iobroker npm ls canvas -
@dirkhe sagte in Mihome Vacuum Karte:
Das wird dann die canvas lib sein, die muß wahrscheinlich neu gebildet werden.
Möglich. Aber die sollte eigentlich den Kernel kalt lassen.
Wie schaut denn canvas aus?
cd /opt/iobroker npm ls canvas@thomas-braun ich gehe davon aus, dass der Speicher falsch angesprochen wird, man sieht da ja, dass er auf falsche Speicherbereiche zugreifen will. Sieht füt mich nach 32 und 64 bit mix aus
-
@dirkhe sagte in Mihome Vacuum Karte:
Das wird dann die canvas lib sein, die muß wahrscheinlich neu gebildet werden.
Möglich. Aber die sollte eigentlich den Kernel kalt lassen.
Wie schaut denn canvas aus?
cd /opt/iobroker npm ls canvas@thomas-braun said in Mihome Vacuum Karte:
Wie schaut denn canvas aus?
cd /opt/iobroker npm ls canvasiobroker.inst@2.0.3 /opt/iobroker └─┬ iobroker.mihome-vacuum@3.5.0 └── canvas@2.9.3 -
@thomas-braun ich gehe davon aus, dass der Speicher falsch angesprochen wird, man sieht da ja, dass er auf falsche Speicherbereiche zugreifen will. Sieht füt mich nach 32 und 64 bit mix aus
@dirkhe sagte in Mihome Vacuum Karte:
Sieht füt mich nach 32 und 64 bit mix aus
Ja, das könnte sein.
Aber wie bekommt man so einen Mix rein? Der Paketmanager zieht eigentlich die richtige Archtiektur rein... -
@thomas-braun said in Mihome Vacuum Karte:
Wie schaut denn canvas aus?
cd /opt/iobroker npm ls canvasiobroker.inst@2.0.3 /opt/iobroker └─┬ iobroker.mihome-vacuum@3.5.0 └── canvas@2.9.3uname -a apt policy build-essential libcairo2-dev libpango1.0-dev libjpeg-dev libgif-dev librsvg2-devsagt?
-
@dirkhe sagte in Mihome Vacuum Karte:
Sieht füt mich nach 32 und 64 bit mix aus
Ja, das könnte sein.
Aber wie bekommt man so einen Mix rein? Der Paketmanager zieht eigentlich die richtige Archtiektur rein...@thomas-braun ich hatte das letztens auch auf meinem raspi, nicht mit dem canvas, sondern mit dem ble adapter. Da waren irgendwelche structs in headern bereits auf 64bit gestzt, obwohl es ein 32bit System ist. An andere Stelle habe ich auch irgendwo gelesen, dass nodejs 32bit auch nicht mehr unterstützt.
-
@dirkhe sagte in Mihome Vacuum Karte:
Sieht füt mich nach 32 und 64 bit mix aus
Ja, das könnte sein.
Aber wie bekommt man so einen Mix rein? Der Paketmanager zieht eigentlich die richtige Archtiektur rein...@thomas-braun
Kann schon sein dass ich da viel Quatsch gemacht habe - hatte schonmal Probleme mit der Karte gehabt und hatte da Tipps gefunden wie man canvas nach installiert.
Dachte aber mit deinstallieren und installieren des Adapters baut er mit allen Abhängigkeiten neu. Evtl hätte ich aber vor der Adapter Neuinstallation auch erstmal gezielt auch die canvas lib nochmal runternehmen? Wenn ja, wie würde ich das machen können? -
uname -a apt policy build-essential libcairo2-dev libpango1.0-dev libjpeg-dev libgif-dev librsvg2-devsagt?
@thomas-braun said in Mihome Vacuum Karte:
uname -a apt policy build-essential libcairo2-dev libpango1.0-dev libjpeg-dev libgif-dev librsvg2-devsagt?
Linux haustuerpi 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linuxbuild-essential: Installiert: 12.6 Installationskandidat: 12.6 Versionstabelle: *** 12.6 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages 100 /var/lib/dpkg/status libcairo2-dev: Installiert: 1.16.0-4+rpt1 Installationskandidat: 1.16.0-4+rpt1 Versionstabelle: *** 1.16.0-4+rpt1 500 500 http://archive.raspberrypi.org/debian buster/main armhf Packages 100 /var/lib/dpkg/status 1.16.0-4+deb10u1 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages libpango1.0-dev: Installiert: 1.42.4-8~deb10u1 Installationskandidat: 1.42.4-8~deb10u1 Versionstabelle: *** 1.42.4-8~deb10u1 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages 100 /var/lib/dpkg/status libjpeg-dev: Installiert: 1:1.5.2-2+deb10u1 Installationskandidat: 1:1.5.2-2+deb10u1 Versionstabelle: *** 1:1.5.2-2+deb10u1 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages 100 /var/lib/dpkg/status libgif-dev: Installiert: 5.1.4-3 Installationskandidat: 5.1.4-3 Versionstabelle: *** 5.1.4-3 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages 100 /var/lib/dpkg/status librsvg2-dev: Installiert: 2.44.10-2.1+rpi1 Installationskandidat: 2.44.10-2.1+rpi1 Versionstabelle: *** 2.44.10-2.1+rpi1 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages 100 /var/lib/dpkg/status -
@thomas-braun said in Mihome Vacuum Karte:
uname -a apt policy build-essential libcairo2-dev libpango1.0-dev libjpeg-dev libgif-dev librsvg2-devsagt?
Linux haustuerpi 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linuxbuild-essential: Installiert: 12.6 Installationskandidat: 12.6 Versionstabelle: *** 12.6 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages 100 /var/lib/dpkg/status libcairo2-dev: Installiert: 1.16.0-4+rpt1 Installationskandidat: 1.16.0-4+rpt1 Versionstabelle: *** 1.16.0-4+rpt1 500 500 http://archive.raspberrypi.org/debian buster/main armhf Packages 100 /var/lib/dpkg/status 1.16.0-4+deb10u1 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages libpango1.0-dev: Installiert: 1.42.4-8~deb10u1 Installationskandidat: 1.42.4-8~deb10u1 Versionstabelle: *** 1.42.4-8~deb10u1 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages 100 /var/lib/dpkg/status libjpeg-dev: Installiert: 1:1.5.2-2+deb10u1 Installationskandidat: 1:1.5.2-2+deb10u1 Versionstabelle: *** 1:1.5.2-2+deb10u1 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages 100 /var/lib/dpkg/status libgif-dev: Installiert: 5.1.4-3 Installationskandidat: 5.1.4-3 Versionstabelle: *** 5.1.4-3 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages 100 /var/lib/dpkg/status librsvg2-dev: Installiert: 2.44.10-2.1+rpi1 Installationskandidat: 2.44.10-2.1+rpi1 Versionstabelle: *** 2.44.10-2.1+rpi1 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages 100 /var/lib/dpkg/statusPasst soweit.
Aber vielleicht wäre es auch eine gute Gelegenheit ein 64bit-Bullseye frisch zu installieren und dort ein Backup des iobrokers einzuspielen.Buster erreicht ohnehin in wenigen Wochen das EndOfLife.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden376
Online32.8k
Benutzer82.7k
Themen1.3m
Beiträge