NEWS
Debian Log-Files werden zugemüllt mit kernel-Commands
-
Hallo. Ich weiß, dass gehört nicht zum iobroker aber evtl. kann mir hier jemand helfen.
Unter /var/log werden wachsen plötzlich die Files "messages" "kern.log" und "syslog" so stark bis kein Speicher mehr frei ist. Das habe ich nur gemerkt, weil plötzlich der iobroker nicht mehr wollte.Die Meldungen kommen wohl vom kernel und sehen in alles drei Files sehr ähnlich aus:
Jun 9 11:40:45 Raspi3 kernel: [ 5571.694082] [0bd19f80] TCM< 82426f7c 0 Jun 9 11:40:45 Raspi3 kernel: [ 5571.694092] [0bd19f81] CMD< c 0 Jun 9 11:40:45 Raspi3 kernel: [ 5571.694103] [0bd19f85] TCM> 82426f7c 0 Jun 9 11:40:45 Raspi3 kernel: [ 5571.694113] [0bd19f85] FDA> 82426ea8 82426f4c Jun 9 11:40:45 Raspi3 kernel: [ 5571.694123] [0bd19f86] DMA> 0 0 Jun 9 11:40:45 Raspi3 kernel: [ 5571.694133] [0bd1a203] IRQ< 400 0 Jun 9 11:40:45 Raspi3 kernel: [ 5571.694144] [0bd1a204] IRQB 82426f4c 400 Jun 9 11:40:45 Raspi3 kernel: [ 5571.694154] [0bd1a204] FCM< 82426ea8 82426f4c Jun 9 11:40:45 Raspi3 kernel: [ 5571.694164] [0bd1a205] RSP c00 0 Jun 9 11:40:45 Raspi3 kernel: [ 5571.694174] [0bd1a206] FCM> 82426ea8 82426f4c Jun 9 11:40:45 Raspi3 kernel: [ 5571.694184] [0bd1a206] IRQ> 0 0 ....Weiß jemand wo das herkommt, bzw. wie ich das wieder loswerden kann?
Ein Neustart hat nichts geändert.
Das erzeugt grob 5MB die Stunde pro File und der Raspi3 wird entsprechend träge.
Danke -
@djmarc75 sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
iob diag
Ok, mach ich gerne, ich weiß aber nicht ob der iobroker für das Problem überhaupt verantwortlich ist.
Diese komische Log-File Überflutung kommt ja vom Kernel, daher gehe ich eher nicht vom iobroker aus.======================= SUMMARY ======================= v.2023-04-16 Operatingsystem: Raspbian GNU/Linux 10 (buster) Kernel: 5.10.103-v7+ Installation: Native Timezone: Europe/Berlin (CEST, +0200) User-ID: 1000 X-Server: false Boot Target: graphical.target Pending OS-Updates: 27 Pending iob updates: 23 Nodejs-Installation: /usr/bin/nodejs v16.19.0 /usr/bin/node v16.19.0 /usr/bin/npm 8.19.3 /usr/bin/npx 8.19.3 Recommended versions are nodejs 18.x.y and npm 9.x.y Your nodejs installation is correct MEMORY: total used free shared buff/cache available Mem: 923M 359M 99M 46M 464M 488M Swap: 99M 58M 41M Total: 1.0G 418M 140M Active iob-Instances: 28 Active repo(s): stable ioBroker Core: js-controller 4.0.24 admin 6.2.17 ioBroker Status: iobroker is running on this host. Objects type: jsonl States type: jsonl Status admin and web instance: + system.adapter.admin.1 : admin : Raspi3 - enabled, port: 8089, bind: 0.0.0.0, run as: admin + system.adapter.admin.2 : admin : Raspi4 - enabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin + system.adapter.admin.3 : admin : Raspi4 - enabled, port: 8083, bind: 0.0.0.0, run as: admin + system.adapter.web.0 : web : Raspi4 - enabled, port: 8082, bind: 0.0.0.0, run as: admin + system.adapter.web.1 : web : Raspi4 - enabled, port: 1443, bind: 0.0.0.0 (SSL), run as: admin Objects: 8989 States: 7412 Size of iob-Database: 22M /opt/iobroker/iobroker-data/objects.jsonl 9.1M /opt/iobroker/iobroker-data/objects.json.migrated 9.1M /opt/iobroker/iobroker-data/objects.json.bak.migrated 9.1M /opt/iobroker/iobroker-data/2022-03-13_08-35_objects.json 0 /opt/iobroker/iobroker-data/objects.json.broken 12M /opt/iobroker/iobroker-data/states.jsonl 1.1M /opt/iobroker/iobroker-data/states.json.migrated 1.1M /opt/iobroker/iobroker-data/states.json.bak.migrated 1.1M /opt/iobroker/iobroker-data/2022-03-13_07-30_states.json 0 /opt/iobroker/iobroker-data/states.json.broken =================== END OF SUMMARY ====================Die 23 iob update beziehen sich übrigens auf den Raspi-module auf dem Raspi3, die aber in der aktuellen Version auf dem Raspi4 laufen. Und ja es sind nicht die neuesten node/npm Versionen. Ich denke aber das ist für das Fehlerbild unerheblich.
-
@tottbeck sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
buster
Kannste direkt auf Bullseye bringen, buster ist längst abgekündigt.
Vermutlich ergibt sich da direkt dein Problem gleich mit. -
@djmarc75 sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
iob diag
Ok, mach ich gerne, ich weiß aber nicht ob der iobroker für das Problem überhaupt verantwortlich ist.
Diese komische Log-File Überflutung kommt ja vom Kernel, daher gehe ich eher nicht vom iobroker aus.======================= SUMMARY ======================= v.2023-04-16 Operatingsystem: Raspbian GNU/Linux 10 (buster) Kernel: 5.10.103-v7+ Installation: Native Timezone: Europe/Berlin (CEST, +0200) User-ID: 1000 X-Server: false Boot Target: graphical.target Pending OS-Updates: 27 Pending iob updates: 23 Nodejs-Installation: /usr/bin/nodejs v16.19.0 /usr/bin/node v16.19.0 /usr/bin/npm 8.19.3 /usr/bin/npx 8.19.3 Recommended versions are nodejs 18.x.y and npm 9.x.y Your nodejs installation is correct MEMORY: total used free shared buff/cache available Mem: 923M 359M 99M 46M 464M 488M Swap: 99M 58M 41M Total: 1.0G 418M 140M Active iob-Instances: 28 Active repo(s): stable ioBroker Core: js-controller 4.0.24 admin 6.2.17 ioBroker Status: iobroker is running on this host. Objects type: jsonl States type: jsonl Status admin and web instance: + system.adapter.admin.1 : admin : Raspi3 - enabled, port: 8089, bind: 0.0.0.0, run as: admin + system.adapter.admin.2 : admin : Raspi4 - enabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin + system.adapter.admin.3 : admin : Raspi4 - enabled, port: 8083, bind: 0.0.0.0, run as: admin + system.adapter.web.0 : web : Raspi4 - enabled, port: 8082, bind: 0.0.0.0, run as: admin + system.adapter.web.1 : web : Raspi4 - enabled, port: 1443, bind: 0.0.0.0 (SSL), run as: admin Objects: 8989 States: 7412 Size of iob-Database: 22M /opt/iobroker/iobroker-data/objects.jsonl 9.1M /opt/iobroker/iobroker-data/objects.json.migrated 9.1M /opt/iobroker/iobroker-data/objects.json.bak.migrated 9.1M /opt/iobroker/iobroker-data/2022-03-13_08-35_objects.json 0 /opt/iobroker/iobroker-data/objects.json.broken 12M /opt/iobroker/iobroker-data/states.jsonl 1.1M /opt/iobroker/iobroker-data/states.json.migrated 1.1M /opt/iobroker/iobroker-data/states.json.bak.migrated 1.1M /opt/iobroker/iobroker-data/2022-03-13_07-30_states.json 0 /opt/iobroker/iobroker-data/states.json.broken =================== END OF SUMMARY ====================Die 23 iob update beziehen sich übrigens auf den Raspi-module auf dem Raspi3, die aber in der aktuellen Version auf dem Raspi4 laufen. Und ja es sind nicht die neuesten node/npm Versionen. Ich denke aber das ist für das Fehlerbild unerheblich.
@tottbeck sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
Active iob-Instances: 28
bei
@tottbeck sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
Mem: 923M
und trotzdem noch
@tottbeck sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
available 488M
wie machst du das?
bein1GB ist üblicherweise bein10 Instanzen Schluss -
@tottbeck sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
Active iob-Instances: 28
bei
@tottbeck sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
Mem: 923M
und trotzdem noch
@tottbeck sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
available 488M
wie machst du das?
bein1GB ist üblicherweise bein10 Instanzen Schluss@homoran sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
wie machst du das?
bein1GB ist üblicherweise bein10 Instanzen SchlussIst ein Master Slave System. Nur 4 Instanzen laufen auf dem Raspi3 (Master), der Rest auf dem Raspi4 (Slave)
Die Diskussion wegen buster/bullseye hatten wir schon mal.
Im Raspberry-Imager wird aber auch noch eine aktuelle Buster-Version angeboten
Ja, ich muss den Schnitt zum bullseye natürlich bald mal machen und dann möglichst auch Master/Slave-Rolle tauschen, aber warum sollte das für kernel-Log-Fehler verantwortlich sein? -
@homoran sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
wie machst du das?
bein1GB ist üblicherweise bein10 Instanzen SchlussIst ein Master Slave System. Nur 4 Instanzen laufen auf dem Raspi3 (Master), der Rest auf dem Raspi4 (Slave)
Die Diskussion wegen buster/bullseye hatten wir schon mal.
Im Raspberry-Imager wird aber auch noch eine aktuelle Buster-Version angeboten
Ja, ich muss den Schnitt zum bullseye natürlich bald mal machen und dann möglichst auch Master/Slave-Rolle tauschen, aber warum sollte das für kernel-Log-Fehler verantwortlich sein?@tottbeck sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
Die Diskussion wegen buster/bullseye hatten wir schon mal.
Da gibt's nix zu diskutieren.
-
@homoran sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
wie machst du das?
bein1GB ist üblicherweise bein10 Instanzen SchlussIst ein Master Slave System. Nur 4 Instanzen laufen auf dem Raspi3 (Master), der Rest auf dem Raspi4 (Slave)
Die Diskussion wegen buster/bullseye hatten wir schon mal.
Im Raspberry-Imager wird aber auch noch eine aktuelle Buster-Version angeboten
Ja, ich muss den Schnitt zum bullseye natürlich bald mal machen und dann möglichst auch Master/Slave-Rolle tauschen, aber warum sollte das für kernel-Log-Fehler verantwortlich sein?@tottbeck sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
Ja, ich muss den Schnitt zum bullseye natürlich bald mal machen
Die Tage wird schon das Nachfolgerelease 'Bookworm' Debian12 erwartet, 'Bullseye' verabschiedet sich also im Sommer 2024 und die Übergangsphase dahin startet mit Release von Debian 12.
-
"sudo apt dist-upgrade -y" (noch mit buster) bringt
Preparing to unpack .../13-raspberrypi-kernel_1%3a1.20230509~buster-1_armhf.deb... Adding 'diversion of /boot/kernel.img to /usr/share/rpikernelhack/kernel.img by rpikernelhack' dpkg-divert: error: cannot copy '/boot/kernel.img' to '/usr/share/rpikernelhack/kernel.img.dpkg-divert.tmp': failed to read (Input/output error) dpkg: error processing archive /tmp/apt-dpkg-install-uzKoHr/13-raspberrypi-kernel_1%3a1.20230509~buster-1_armhf.deb (--unpack): new raspberrypi-kernel package pre-installation script subprocess returned error exit status 2Evtl. ein Problem mit der SD-Card ? Ich werde mal die kernel.img überschreiben.
-
"sudo apt dist-upgrade -y" (noch mit buster) bringt
Preparing to unpack .../13-raspberrypi-kernel_1%3a1.20230509~buster-1_armhf.deb... Adding 'diversion of /boot/kernel.img to /usr/share/rpikernelhack/kernel.img by rpikernelhack' dpkg-divert: error: cannot copy '/boot/kernel.img' to '/usr/share/rpikernelhack/kernel.img.dpkg-divert.tmp': failed to read (Input/output error) dpkg: error processing archive /tmp/apt-dpkg-install-uzKoHr/13-raspberrypi-kernel_1%3a1.20230509~buster-1_armhf.deb (--unpack): new raspberrypi-kernel package pre-installation script subprocess returned error exit status 2Evtl. ein Problem mit der SD-Card ? Ich werde mal die kernel.img überschreiben.
Ne, neue sd Karte
Dann kennst du jetzt auch den Grund für die Kernel Meldungen -
Richtig. Und dann halt direkt auch ein noch unterstütze Version installieren.
-
Ich habe des Raspi 3 nun mit bullseye und iobroker mit aktuellem npm/node neu aufgesetzt. Das dauerte zwar ziemlich lange trotz Backup, aber nun läuft fast alles wieder. Was mir aufgefallen ist: Die GPIOs gehen nicht mehr, da habe ich ein paar Kontakte an Relaiskarte im Schaltschrank angeschlossen (Türklingel, Garagentor .. ).
Ich habe die bisher über Systeminfo-Adapter angesteuert, welcher wohl über WiringPi (gpio write x) arbeitet.
Da WiringPi nicht mehr im bullseye vorhanden ist und auch nicht (oder nur indirekt) nachinstalliert werden kann muss ich mich wohl um Alternativen bemühen. Per "raspi-gpio"-Kommandos müsste es funktionieren, aber die verwenden einen anderen Syntax, den ich im Systeminfo-Adapter anpassen müsste.
Das war mit ein Grund warum ich ein ansonsten lauffähiges System nicht mal eben portieren wollte. Irgendetwas ist dann immer. GPIO läuft aber jetzt wieder mit WiringPi Nachinstallation.
Die Speicherkarte war übrigens eine SanDisk-Industrial 8GB. Hat aber nach ca. 3 Jahren trotzdem die Grätsche gemacht. -
Ich habe des Raspi 3 nun mit bullseye und iobroker mit aktuellem npm/node neu aufgesetzt. Das dauerte zwar ziemlich lange trotz Backup, aber nun läuft fast alles wieder. Was mir aufgefallen ist: Die GPIOs gehen nicht mehr, da habe ich ein paar Kontakte an Relaiskarte im Schaltschrank angeschlossen (Türklingel, Garagentor .. ).
Ich habe die bisher über Systeminfo-Adapter angesteuert, welcher wohl über WiringPi (gpio write x) arbeitet.
Da WiringPi nicht mehr im bullseye vorhanden ist und auch nicht (oder nur indirekt) nachinstalliert werden kann muss ich mich wohl um Alternativen bemühen. Per "raspi-gpio"-Kommandos müsste es funktionieren, aber die verwenden einen anderen Syntax, den ich im Systeminfo-Adapter anpassen müsste.
Das war mit ein Grund warum ich ein ansonsten lauffähiges System nicht mal eben portieren wollte. Irgendetwas ist dann immer. GPIO läuft aber jetzt wieder mit WiringPi Nachinstallation.
Die Speicherkarte war übrigens eine SanDisk-Industrial 8GB. Hat aber nach ca. 3 Jahren trotzdem die Grätsche gemacht.wiringpi sollte eh nicht mehr verwendet werden.
-
Ich habe des Raspi 3 nun mit bullseye und iobroker mit aktuellem npm/node neu aufgesetzt. Das dauerte zwar ziemlich lange trotz Backup, aber nun läuft fast alles wieder. Was mir aufgefallen ist: Die GPIOs gehen nicht mehr, da habe ich ein paar Kontakte an Relaiskarte im Schaltschrank angeschlossen (Türklingel, Garagentor .. ).
Ich habe die bisher über Systeminfo-Adapter angesteuert, welcher wohl über WiringPi (gpio write x) arbeitet.
Da WiringPi nicht mehr im bullseye vorhanden ist und auch nicht (oder nur indirekt) nachinstalliert werden kann muss ich mich wohl um Alternativen bemühen. Per "raspi-gpio"-Kommandos müsste es funktionieren, aber die verwenden einen anderen Syntax, den ich im Systeminfo-Adapter anpassen müsste.
Das war mit ein Grund warum ich ein ansonsten lauffähiges System nicht mal eben portieren wollte. Irgendetwas ist dann immer. GPIO läuft aber jetzt wieder mit WiringPi Nachinstallation.
Die Speicherkarte war übrigens eine SanDisk-Industrial 8GB. Hat aber nach ca. 3 Jahren trotzdem die Grätsche gemacht. -
Ich habe des Raspi 3 nun mit bullseye und iobroker mit aktuellem npm/node neu aufgesetzt. Das dauerte zwar ziemlich lange trotz Backup, aber nun läuft fast alles wieder. Was mir aufgefallen ist: Die GPIOs gehen nicht mehr, da habe ich ein paar Kontakte an Relaiskarte im Schaltschrank angeschlossen (Türklingel, Garagentor .. ).
Ich habe die bisher über Systeminfo-Adapter angesteuert, welcher wohl über WiringPi (gpio write x) arbeitet.
Da WiringPi nicht mehr im bullseye vorhanden ist und auch nicht (oder nur indirekt) nachinstalliert werden kann muss ich mich wohl um Alternativen bemühen. Per "raspi-gpio"-Kommandos müsste es funktionieren, aber die verwenden einen anderen Syntax, den ich im Systeminfo-Adapter anpassen müsste.
Das war mit ein Grund warum ich ein ansonsten lauffähiges System nicht mal eben portieren wollte. Irgendetwas ist dann immer. GPIO läuft aber jetzt wieder mit WiringPi Nachinstallation.
Die Speicherkarte war übrigens eine SanDisk-Industrial 8GB. Hat aber nach ca. 3 Jahren trotzdem die Grätsche gemacht.@tottbeck
Wahrscheinlich ist im Debian Image der Treiber für raspi gpio nicht enthalten.
Durch Installation von wiringpi wurde der Treiber über die Abhängigkeiten wieder installiert.Das kapseln von Funktionalität in Docker Container ist mittlerweile mein Ansatz.
Das Host Betriebssystem so original lassen wie möglich. Alle software in ein oder mehrere Docker Container packen.
Und alles kann unabhängig voneinander ohne Probleme aktualisiert werden.
Die ganzen Abhängigkeiten der Container zum Host betriebssystem oder Hardware in Docker Compose Dateien dokumentiert -
echad@chet:~ $ apt policy pigpio pigpio: Installed: (none) Candidate: 1.79-1+rpt1 Version table: 1.79-1+rpt1 500 500 http://archive.raspberrypi.org/debian bullseye/main arm64 Packages echad@chet:~ $Ist halt eine library von/für Raspberry OS und kommt daher auch aus deren Repo.
-
wiringpi sollte eh nicht mehr verwendet werden.
@thomas-braun sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
wiringpi sollte eh nicht mehr verwendet werden.
Danke für den Hinweis. WiringPi wird nicht mehr maintained und ist daher verständlicherweise rausgeflogen. Funktional bieten die anderen GPIO-Lösungen soweit ich sagen kann keinen Unterschied. Ich werden mich wohl eh über kurz oder lang von den Relaiskarte verabschieden und dafür Shellys oder ähnliches verwenden. Ist so einfach besser pflegbar.
Support us
680
Online32.6k
Benutzer82.0k
Themen1.3m
Beiträge