UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[apollon77]

Und weil es so schön ist (Das war zuviel Log scheinbar ... diesmal Holz-klopf) ... 4.0.21 :-(

(leider gabs doch noch was bei Backup Restore ...)

Auf dem Weg in Beta

Ingo

[amg_666]

@apollon77 iob auf nuc mit proxmox/debian als container und ein Slave auf raspi pi 3b. Beide sind jetzt auf 4.0.21, läuft alles wunderbar, keine Auffälligkeiten in den logs
Restore habe ich nicht getestet, aber backup läuft sauber durch inkl Sicheruing auf NAS.

[SBorg]

4.0.21 lüppt :+1:

(und nicht mehr per iob upgrade self probiert...)

[da_Woody]

@apollon77 flutsch! :+1: :blush:

[Feuersturm]

@apollon77 Auch hier gibt es keine Probleme mit der 4.0.21 :clap:

[Feuersturm]

@apollon77 Es gab aber wohl keine Änderungen ;-)

[lonsimbt]

@apollon77
4.0.21 läuft

[apollon77]

@feuersturm Fixe ich nachher noch ...

[apollon77]

Hallo an die Beta Front :-)

Morgen früh dürfte js-controller 4.0.23 im beta/Latest auftauchen. Ein Admin Bug der eine ungültige Jsonl-Konfiguration generieren konnte hat uns dazu gezwungen doch nochmals nachzulegen. Von dem problem akut betroffen sein könnten user die per Admin die Host-Konfiguration geändert und gespeichert haben.

Falls bei jemandem der js-controller nicht mehr sauber startet (vor oder auch nach dem update) bitte die größe der /opt/iobroker/iobroker-data/*.jsonl Dateien prüfen ... ggf hat bei Ihm dieses problem zugeschlagen -> siehe auch https://forum.iobroker.net/topic/53954/gelöst-states-jsonl-file-viel-zu-groß bzw https://forum.iobroker.net/post/791284

Der Bug ist auch seit Admin 5.3.7 behoben und Admin sollte nicht mehr die falschen Einträge erstellen.

Am besten natürlich sicherheitshalber besser Updaten :-)

4.0.23 (2022-04-19)

• (AlCalzone) normalize JSONL options to prevent issues because of admin adding empty setting objects
• (Apollon77/foxriver76) Prevent some crash cases reported by Sentry

[Diginix]

@apollon77 .23 läuft unauffällig

Ich habe mal meine iobroker.json Einstellungen für objects und states gecheckt.
Und gesehen, dass ich für ein geringeres Schreibaufkommen auf SSD folgendes in der Vergangenheit vor JSONL Einführung eingestellt habe:

"objects": {
    "writeFileInterval": 3600000,
...
  "states": {
    "writeFileInterval": 60000,
...

Default wäre ja objects alle 5000 ms (720x häufiger) und states alle 30000 ms (doppelt so oft).
Was ist hier bei JSONL sinnvoll? Würde ich von 3600 s bei objects auf 5 s herunter gehen, würde ja nicht wie bei JSON früher die gesamten >30 MB neu geschrieben, aber dennoch würde das häufigere anhängen zu einem früheren Komprimieren führen oder?
Oder werden diese Interval Einstellungen gar ignoriert seit JSONL?
Der Zeitstempel meiner objects.jsonl lässt das vermuten.

[apollon77]

@diginix writeFileInterval wird von jsonl gar nicht verwendet, von daher "egal" :-) Das nutzt nur die "alte" File-DB. Jsonl hat eigene Settings https://github.com/ioBroker/ioBroker.js-controller/blob/master/packages/controller/conf/iobroker-dist.json#L53-L71

[fastfoot]

@apollon77 update im Container problemlos :-)

[amg_666]

@apollon77 Master ist ein Container mit Debian10 uinter proxmox, Slave ein Raspi 3b. Läuft jetzt seit einigen Stunden völlig unauffällig.

[Feuersturm]

@apollon77 Auch bei meinem Master Slave Testsystem gibt es bisher keine Auffälligkeiten mit der 4.0.23

[Jabba_the_Hutt]

Code 22?

Was soll mir das sagen ... wenn sich die neue Version nicht installieren lässt?

[apollon77]

@jabba_the_hutt dann gibts irgendein issue in deinem npm tree. Rufe das Upgrade Self mal mit --debug auf. Was kommt dann?

[Jabba_the_Hutt]

k.A. was da los war ... jetzt ist es ohne Probleme durchgelaufen.

SRY für den falschen Alarm.

[Dolomiti]

Update vom ioBroker-Test im LXC ohne Probs durchgelaufen.
Raspi 3B will nicht. System is uptodate

pi@ioBroker-Slave:/opt/iobroker $ which nodejs node npm && nodejs -v && node -v && npm -v && sudo apt update && sudo apt update && apt policy nodejs
/usr/bin/nodejs
/usr/bin/node
/usr/bin/npm
v14.19.1
v14.19.1
6.14.16
OK:1 http://raspbian.raspberrypi.org/raspbian bullseye InRelease
OK:2 http://archive.raspberrypi.org/debian bullseye InRelease
OK:3 https://deb.nodesource.com/node_14.x bullseye InRelease
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Alle Pakete sind aktuell.
OK:1 http://raspbian.raspberrypi.org/raspbian bullseye InRelease
OK:2 http://archive.raspberrypi.org/debian bullseye InRelease
OK:3 https://deb.nodesource.com/node_14.x bullseye InRelease
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Alle Pakete sind aktuell.
nodejs:
  Installiert:           14.19.1-deb-1nodesource1
  Installationskandidat: 14.19.1-deb-1nodesource1
  Versionstabelle:
 *** 14.19.1-deb-1nodesource1 500
        500 https://deb.nodesource.com/node_14.x bullseye/main armhf Packages
        100 /var/lib/dpkg/status
     12.22.5~dfsg-2~11u1 500
        500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages
pi@ioBroker-Slave:/opt/iobroker $

Danach

pi@ioBroker-Slave:/opt/iobroker $ iob status
iobroker is running on this host.


Objects type: jsonl
States  type: jsonl
pi@ioBroker-Slave:/opt/iobroker $ iob -v
4.0.21
pi@ioBroker-Slave:/opt/iobroker $

Dann

iob backup
iob stop
iob update
iob fix

Bis hierher ohne Auffälligkeiten. Aber bei

pi@ioBroker-Slave:/opt/iobroker $ iobroker upgrade self --debug
No connection to databases possible ...
pi@ioBroker-Slave:/opt/iobroker $

Kommt nach ca. 30s die no connection-Meldung. Wenn ich iob start oder einen Reboot mache läuft das System sauber hoch. Die ganzen vorherigen Updates von 3.x.x auf 4.x.x haben immer problemlos funktioniert.

[apollon77]

@dolomiti Wie gross sind deine jsonl Files?

[Kueppert]

Haba auch seit 2 Tagen kein ioBroker mehr. Mein Uralt-System hat sich ab 2:30 Uhr nachts mit 120% Dauerauslastung unerreichbar gemacht. Ich dachte bei mir: egal, hast ja Proxmox...machst einfach nen Backup drauf, fertig...
keine Chance. Immer das gleiche Fehlerbild: Auslastung CPU 120% dauerhaft, Admin nicht erreichbar...Update JS-Controller wegen no connection to database (jsonl) nicht möglich.

Was hab ich bereits gemacht:
iobroker fixer drüber gejagt (alles gut, keine negativen Meldungen)
Update via apt update & apt disp-upgrade
Neustart
mal auf file umgestellt via iobroker custom setup ohne Übernahme der alten Datenpunkte...alles nix geholfen.

Kann doch nicht sein, dass selbst 1 Woche alte Backups (hab jetzt 4 verschiedene ausprobiert) nicht mehr laufen?

JS-Controler ist 4.0.21 noch drauf.
kein Multihost
ioBroker läuft auf einem NUC mit 32GB Partition und 5GB RAM
InfluxDB hab ich auch auf dem HOST, weil ich auf einem LXC auch Grafana + InfluxDB nutze

Wenn es keinen "mache mal folgenden Ablauf" gibt, kann ich gern alle benötigten Infos (sofern ich eine Rückmeldung vom System erhalte) beibringen. Bei 120% Auslastung dauert das immer etwas (sofern ich den iob nicht vorher beende ^^)

INFOS inkl. Fehlermeldungen nach frischem Backup-Restore:

thorsten@ioBroker2:~$ which nodejs node npm && nodejs -v && node -v && npm -v
/usr/bin/nodejs
/usr/bin/node
/usr/bin/npm
v14.19.1
v14.19.1
6.14.16
thorsten@ioBroker2:~$ iob status
 Cannot load "variables": Connection is closed.
 Cannot initialize database scripts: Cannot load "variables" into objects database: Connection is closed.
Server Cannot start inMem-objects on port 9001: Failed to lock DB file "/opt/iobroker/iobroker-data/objects.jsonl"!
thorsten@ioBroker2:~$ iob -v
4.0.21
thorsten@ioBroker2:~$ df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
udev            2,5G       0  2,5G    0% /dev
tmpfs           496M    6,7M  489M    2% /run
/dev/sda1        29G     15G   13G   54% /
tmpfs           2,5G       0  2,5G    0% /dev/shm
tmpfs           5,0M       0  5,0M    0% /run/lock
tmpfs           2,5G       0  2,5G    0% /sys/fs/cgroup
tmpfs           496M       0  496M    0% /run/user/1000

Größe jsonl-files: