NEWS
[gelöst] Versuch Logdatei download führt zu Admin-Absturz
-
@maloross sieht "eigentlich" gut aus.
der Swap ist noch nicht angegriffen.ALLERDINGS muss man dabei wissen, ob der Raspi nach dem Problem neu gestartet ist.
Dann sagt der Wert nichts aus. -
@homoran Das kann ich so jetzt nicht sagen, werde es aber im Auge behalten.
Wenn ich dich richtig verstehe, ist die Größe der Auslagerungsdatei (free Swap) der Indikator, das RAM ungenügend zur Verfügung steht.
Ich vermute, über den Adapter "RPI-Monitor" kann man sich diese (und andere) relevanten Werte anzeigen lassen. Hatte den mal vor langer Zeit getestet, aber nicht genutzt. -
@maloross sagte in Versuch Logdatei download führt zu Admin-Absturz:
ist die Größe der Auslagerungsdatei (free Swap) der Indikator, das RAM ungenügend zur Verfügung steht.
jein, used SWAP sollte möglichst nicht angekratzt sein
@maloross sagte in Versuch Logdatei download führt zu Admin-Absturz:
über den Adapter "RPI-Monitor" kann man sich diese (und andere) relevanten Werte anzeigen lassen.
oder über die Datenpunkte unter 'system.host.xy' (nur im Expertenmodus zu sehen
-
@homoran sagte in Versuch Logdatei download führt zu Admin-Absturz:
'system.host.xy' (
Super - das ist perfekt! Ich sollte öfter mal in den Expertenmodus wechseln...
-
Heute noch einmal einen Versuch gewagt, jedoch gleiches Ergebnis:
Sobald ich die Logdatei "current" über die Schaltfläche abrufe, knickt der Admin ein und diese Meldung erscheint:host.PI4Slave2 2025-04-14 12:58:30.421 warn "system.host.PI4Master" is offline
Parallel eine Statusabfrage über die Konsole (Putty) warf diese Meldung aus:
supervisor@PI4Master:~ $ iob status Unable to increase LUA script timeout: Connection is closed. Cannot determine Set feature status: Connection is closed. Unable to enable Expiry Keyspace events from Redis Server: Connection is closed. Connection is closed. Uncaught Rejection: Error: States DB is not allowed to start in the current Multihost environment at Redis.<anonymous> (file:///opt/iobroker/node_modules/@iobroker/db-states-redis/build/esm/lib/states/statesInRedisClient.js:477:23) at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
Nach ca. 5 Minuten ist dann der Admin wieder erreichbar und auch die Logdatei wird jetzt im Browser angezeigt. Die durchgeführte Diagnose zeigt im Summary:
======================= SUMMARY ======================= v.2025-02-23 Static hostname: PI4Master Icon name: computer Operating System: Debian GNU/Linux 12 (bookworm) Kernel: Linux 6.12.20+rpt-rpi-v8 Architecture: arm64 Installation: native Kernel: aarch64 Userland: 64 bit Timezone: Europe/Berlin (CEST, +0200) User-ID: 1000 Display-Server: false Boot Target: multi-user.target Pending OS-Updates: 4 Pending iob updates: 0 Nodejs-Installation: /usr/bin/nodejs v20.19.0 /usr/bin/node v20.19.0 /usr/bin/npm 10.8.2 /usr/bin/npx 10.8.2 /usr/bin/corepack 0.31.0 Recommended versions are nodejs 20.19.0 and npm 10.8.2 nodeJS installation is correct MEMORY: total used free shared buff/cache available Mem: 8.2G 4.0G 2.3G 1.5M 2.0G 4.2G Swap: 209M 0B 209M Total: 8.4G 4.0G 2.5G Active iob-Instances: 50 Upgrade policy: none ioBroker Core: js-controller 7.0.6 admin 7.6.3 ioBroker Status: iobroker is running on this host. Objects type: jsonl States type: jsonl Status admin and web instance: + system.adapter.admin.0 : admin : PI4Master - enabled, port: 8081, bind: 0.0.0.0, run as: admin + system.adapter.web.0 : web : PI4Master - enabled, port: 8099, bind: 0.0.0.0, run as: admin system.adapter.web.1 : web : PI4Slave1 - disabled, port: 8899, bind: 0.0.0.0, run as: admin Objects: 26907 States: 22823 Size of iob-Database: 56M /opt/iobroker/iobroker-data/objects.jsonl 38M /opt/iobroker/iobroker-data/states_new.jsonl 12M /opt/iobroker/iobroker-data/states.jsonl Operating System is the current Debian stable version codenamed 'bookworm'! =================== END OF SUMMARY ====================
Über den Raspi2-Adapter lasse ich einige Status überwachen, hier zeigt sich zum Zeitpunkt des Absturzes ein Einbruch im freien Speicher:
Das System selbst lief sehr lange sehr stabil und unauffällig; es stellt sich jetzt die Frage: soll ich das System noch einmal komplett neu und sauber aufsetzen oder soll ich mir Gedanken machen, dass mein System zu groß für die kleinen Rechen geworden ist?
-
Sind für mich typische Anzeichen einer Überlastung.
Vermutlich läuft da in zu kurzer Zeit zuviel in der Datenbank auf und die Kiste bekommt das nicht mehr schnell genug abgearbeitet. -
@thomas-braun sagte in Versuch Logdatei download führt zu Admin-Absturz:
Sind für mich typische Anzeichen einer Überlastung.
Vermutlich läuft da in zu kurzer Zeit zuviel in der Datenbank auf und die Kiste bekommt das nicht mehr schnell genug abgearbeitet.ok, also weniger die Hardware.
Kann ein Umstieg auf Redis (was hier ja schon ausführlich besprochen wird bzw. wurde) Abhilfe schaffen?
Ich werde noch einmal alle Adapter durchgehen und die Abfrageintervalle checken, Adapter wie Fronius sind aber auf 1-2 Minuten eingestellt.
Kann mir da "htop" weiterhelfen und wenn ja, worauf muss ich da achten? -
@maloross sagte in Versuch Logdatei download führt zu Admin-Absturz:
Kann ein Umstieg auf Redis (was hier ja schon ausführlich besprochen wird bzw. wurde) Abhilfe schaffen?
Möglich. Allerdings hast du ja gar nicht sooooo viele Daten. Ich denke eher, da fliegt zu viel zu schnell rein.
Schaumal, ob du da nicht reduzieren kannst.
Alleine der hm--rpc.1 schaufelt da offenbar im Milisekundentakt irgendwas rein:2025-04-13 10:10:33.723 - debug: hm-rpc.1 (3536255) hm-rpc.1.00185BE98B3FD8.1.ILLUMINATION_STATUS ==> UNIT: "undefined" (min: undefined, max: undefined) From "0" => "0" 2025-04-13 10:10:33.724 - debug: hm-rpc.1 (3536255) xml multicall <event>: PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b,00185BE98B3FD8:1,SUNSHINEDURATION,12131 2025-04-13 10:10:33.724 - debug: hm-rpc.1 (3536255) xmlrpc <- event ["PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b","00185BE98B3FD8:1","SUNSHINEDURATION",12131] 2025-04-13 10:10:33.724 - debug: hm-rpc.1 (3536255) hm-rpc.1.00185BE98B3FD8.1.SUNSHINEDURATION ==> UNIT: "min" (min: 0, max: 16383) From "12131" => "12131" 2025-04-13 10:10:33.725 - debug: hm-rpc.1 (3536255) xml multicall <event>: PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b,00185BE98B3FD8:1,HUMIDITY_STATUS,0 2025-04-13 10:10:33.725 - debug: hm-rpc.1 (3536255) xmlrpc <- event ["PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b","00185BE98B3FD8:1","HUMIDITY_STATUS",0] 2025-04-13 10:10:33.725 - debug: hm-rpc.1 (3536255) hm-rpc.1.00185BE98B3FD8.1.HUMIDITY_STATUS ==> UNIT: "undefined" (min: undefined, max: undefined) From "0" => "0" 2025-04-13 10:10:33.725 - debug: hm-rpc.1 (3536255) xml multicall <event>: PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b,00185BE98B3FD8:1,WIND_DIR_RANGE_STATUS,0 2025-04-13 10:10:33.726 - debug: hm-rpc.1 (3536255) xmlrpc <- event ["PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b","00185BE98B3FD8:1","WIND_DIR_RANGE_STATUS",0] 2025-04-13 10:10:33.726 - debug: hm-rpc.1 (3536255) hm-rpc.1.00185BE98B3FD8.1.WIND_DIR_RANGE_STATUS ==> UNIT: "undefined" (min: undefined, max: undefined) From "0" => "0" 2025-04-13 10:10:33.726 - debug: hm-rpc.1 (3536255) xml multicall <event>: PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b,00185BE98B3FD8:1,ACTUAL_TEMPERATURE,13.8 2025-04-13 10:10:33.726 - debug: hm-rpc.1 (3536255) xmlrpc <- event ["PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b","00185BE98B3FD8:1","ACTUAL_TEMPERATURE",13.8] 2025-04-13 10:10:33.726 - debug: hm-rpc.1 (3536255) hm-rpc.1.00185BE98B3FD8.1.ACTUAL_TEMPERATURE ==> UNIT: "�C" (min: -3276.8, max: 3276.7) From "13.8" => "13.8" 2025-04-13 10:10:33.727 - debug: hm-rpc.1 (3536255) xml multicall <event>: PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b,00185BE98B3FD8:1,WIND_DIR_STATUS,0 2025-04-13 10:10:33.727 - debug: hm-rpc.1 (3536255) xmlrpc <- event ["PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b","00185BE98B3FD8:1","WIND_DIR_STATUS",0] 2025-04-13 10:10:33.727 - debug: hm-rpc.1 (3536255) hm-rpc.1.00185BE98B3FD8.1.WIND_DIR_STATUS ==> UNIT: "undefined" (min: undefined, max: undefined) From "0" => "0" 2025-04-13 10:10:33.727 - debug: hm-rpc.1 (3536255) xml multicall <event>: PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b,00185BE98B3FD8:1,RAIN_COUNTER_OVERFLOW,false 2025-04-13 10:10:33.728 - debug: hm-rpc.1 (3536255) xmlrpc <- event ["PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b","00185BE98B3FD8:1","RAIN_COUNTER_OVERFLOW",false] 2025-04-13 10:10:33.728 - debug: hm-rpc.1 (3536255) hm-rpc.1.00185BE98B3FD8.1.RAIN_COUNTER_OVERFLOW ==> UNIT: "undefined" (min: undefined, max: undefined) From "false" => "false" 2025-04-13 10:10:33.728 - debug: hm-rpc.1 (3536255) xml multicall <event>: PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b,00185BE98B3FD8:1,RAINING,false 2025-04-13 10:10:33.728 - debug: hm-rpc.1 (3536255) xmlrpc <- event ["PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b","00185BE98B3FD8:1","RAINING",false] 2025-04-13 10:10:33.729 - debug: hm-rpc.1 (3536255) hm-rpc.1.00185BE98B3FD8.1.RAINING ==> UNIT: "undefined" (min: undefined, max: undefined) From "false" => "false" 2025-04-13 10:10:33.729 - debug: hm-rpc.1 (3536255) xml multicall <event>: PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b,00185BE98B3FD8:1,WIND_SPEED,20.5 2025-04-13 10:10:33.729 - debug: hm-rpc.1 (3536255) xmlrpc <- event ["PI4Master:hm-rpc.1:719f6fd35f68f142a58f1339ad76168b","00185BE98B3FD8:1","WIND_SPEED",20.5] 2025-04-13 10:10:33.730 - debug: hm-rpc.1 (3536255) hm-rpc.1.00185BE98B3FD8.1.WIND_SPEED ==> UNIT: "km/h" (min: 0, max: 200) From "20.5" => "20.5"
-
@thomas-braun Das scheint wohl die Wetterstation (HM-IP) zu sein.
Ich habe die zyklischen Statusmeldungen entfernt, die beiden anderen Werte sind nach meinem Dafürhalten aber weniger problematisch.
Im ioB-Adapter "Homematic" hatte ich die Standardwerte (Verbindungstest180 sec, Wiederverbindung 30 sec.) belassen, habe sie mal verdoppelt. -
@maloross sagte in Versuch Logdatei download führt zu Admin-Absturz:
Das scheint wohl die Wetterstation (HM-IP) zu sein.
ja, aber die anschließend durchgeführten Aktionen sind in meinen Augen wahrscheinlich unnötig.
Das log sieht aus wie nach einem Neustart des Adapters.
Dann wird erst einmal alles eingelesen.Das wäre vollkommen korrekt, wenn es nicht dauernd und vir allem unabsichtlich vorkommt
-
Und dann würde ich die Instanz auch nicht auf 'debug'-Level loggen lassen.
-
@thomas-braun Das die Debug-Einstellung so viel ausmacht hatte ich nicht erwartet. Stelle jetzt alle Adapter, die im Debug sind, auf Info zurück.
Wieder ein Tag, an dem ich Neues gelernt habe. -
@maloross sagte in Versuch Logdatei download führt zu Admin-Absturz:
Stelle jetzt alle Adapter, die im Debug sind, auf Info zurück.
Du hast da auch noch mehrere Instanzen im debug laufen? Kein Wunder, das die Kiste irgendwann dicht macht.
Stell die Adapter noch schweigsamer ein, wenn die stabil laufen. Meine laufen in der Regel auf 'Error' oder 'Warn'. -
@thomas-braun sagte in Versuch Logdatei download führt zu Admin-Absturz:
@maloross sagte in Versuch Logdatei download führt zu Admin-Absturz:
Stelle jetzt alle Adapter, die im Debug sind, auf Info zurück.
Stell die Adapter noch schweigsamer ein, [...]
Fällt mir als kommunikative Frau aber sehr schwer
Wie gesagt, ich geh da immer sehr naiv ran und lerne dann aus den Fehlern.
-
@maloross Nachdem ich alle Adapter zurück auf Info (oder teilweise Error) zurückgeschraubt habe, funktioniert auch die Anzeige der Logdatei auf Anhieb.
Vielen Dank für die Unterstützung und für eure Geduld.