EXPERIMENTELL: JsonL Datenbank für js-controller

[Thomas Braun]

@apollon77 @msauer

root@MSNUC-IOB:/opt/iobroker/node_modules/iobroker.js-controller# npm i @iobroker/db-states-jsonl @iobroker/db-objects-jsonl

Als root macht man das halt auch nicht.
Zusätzlich zum npm@7.

[apollon77]

@thomas-braun Auch wahr ... oder danach "Iobroker fix" aufrufen

[Thomas Braun]

@apollon77
Ich bin an der Stelle ja Verfechter davon gleich sauber mit dem System umzugehen und nicht den ganzen Mist nachträglich per fixer geradeziehen zu müssen.
root-shell ist TABU!
(Außer auf Dockern/Synology. Da geht's ja wohl nicht anders.)

[Kueppert]

hm, ich lese immer wieder, man soll das nicht als root machen...ich mache alles, seit ich Linux nutze, als root (mein, ich hab hier 2016 oder 2017 gestartet). Bei mir war es nämlich genau anders herum: immer wenn ich mit Usern gearbeitet habe, hatte ich Rechte-Probleme, mit root natürlich nie, der darf ja allet.
Inwiefern macht es denn (für mich jetzt zB) Sinn, auf nen User zu schwenken, wenn man die gesamte Heimautomatisierung im Heimnetz betreibt und nur via VPN Zugriff auf diese hat? Ist ne ehrlich gemeinte Frage

[Thomas Braun]

@Kueppert

Dann machst du es seit 2016 oder 2017 falsch.
Bzw. hast das Konzept der Trennung in den user space nicht kapiert.
Wenn dir das System sagt, das darf $USER xyz nicht, dann hat das schon seine Gründe.
Das Setup des ioBrokers basiert darauf, dass es einen user iobroker gibt, der sehr fein abgestimmt gewisse Dinge tun darf oder auch nicht. Gleiches gilt für den Standarduser. Der darf auch nur soviel im System wie notwendig.
root wird garnicht vollständig aktiv sondern die Rechte des root werden nur Fallweise per sudo vom Standarduser übernommen.

Wenn du jetzt das Konzept über den Haufen wirfst reagiert das feinabgestimme Konstrukt anders als vorgesehen.

Ich kenne auch noch andere Zeiten, in denen beim klassischen Installations-Dreisatz aktiv die Rolle gewechselt werden musste und man in einer root-shell aktiv war. Gut das die Zeiten bei den meisten Distributionen vorbei sind. ('Linux' im Einsatz seit 2001 oder so).

Das ganze ist ja kein Designfehler von irgendwem, sondern grundlegend für den Umgang mit dem System. Nicht ohne Grund hat Linux den Ruf stabiler als andere Systeme zu sein. Warum? Weil eben nicht 'Hinz und Kunz' alles drauf werfen darf.
Bei Windows gibt es ja wohl mittlerweile was ähnliches.

[JLeg]

@thomas-braun sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:

Das Setup des ioBrokers basiert darauf, dass es einen user iobroker gibt, der sehr fein abgestimmt gewisse Dinge tun darf oder auch nicht.

echt jetzt? "best practice" in allen Ehren, aber was wäre denn beim User iobroker "sehr fein abgestimmt", ausser dass sein Homedir bzw. Standarddir ihm gehört? Ich wüsste nicht, dass ACLs, apparmor- oder selinux-Templates in Gebrauch wären - oder Ähnliches... (?)

[Thomas Braun]

@jleg
Schau in die sudoers.
ACLs sind auch aktiv.

[JLeg]

@thomas-braun sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:

@jleg
Schau in die sudoers.

Jo, damit werden Einschränkungen selektiv aufgehoben - wird aber durch "root"-Nutzung nicht unmittelbar "zerstört"...

ACLs sind auch aktiv.

bei mir offenbar nicht - klar sind ACLs "aktiv", ich zumindest sehe da aber nur das Standardmapping...

[Thomas Braun]

@jleg
Wenn man weiß was man tut...
Nur die meisten 'Ich bin root, weil ich das System nur so handeln kann'-User wissen es ja eben NICHT.
Und die Kombination 'relative Ahnungslosigkeit' und 'Ungefilterter Vollzugriff auf alles' ist halt denkbar ungünstig.

Die Tage war auch irgendein User hier unterwegs, mit gleich dreifacher Installation von node. Eine in /root, eine in /usr/local/bin und dann eine saubere. Halleluja, das funktioniert alles prima.

Ich bin z. B. auf meinem System noch nie in eine root-shell gewechselt. Wozu auch? Ich hab aber schon im falschen Verzeichnis einen falschen Befehl eingegeben. Als root wäre der durchgeschossen, als Standarduser ist nix passiert.

[JLeg]

@thomas-braun sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:

@jleg
Wenn man weiß was man tut...
Nur die meisten 'Ich bin root, weil ich das System nur so handeln kann'-User wissen es ja eben NICHT.
Und die Kombination 'relative Ahnungslosigkeit' und 'Ungefilterter Vollzugriff auf alles' ist halt denkbar ungünstig.

stimmt natürlich - und ich sehe auch die "didaktische Strategie" - ich würd's halt nicht so dogmatisch rüberbringen wollen...

Die Tage war auch irgendein User hier unterwegs, mit gleich dreifacher Installation von node. Eine in /root, eine in /usr/local/bin und dann eine saubere. Halleluja, das funktioniert alles prima.

Ich bin z. B. auf meinem System noch nie in eine root-shell gewechselt. Wozu auch? Ich hab aber schon im falschen Verzeichnis einen falschen Befehl eingegeben. Als root wäre der durchgeschossen, als Standarduser ist nix passiert.

Erzähl' das einen Windowsuser - ich habe gehört, dass der Standarduser da zur Adminstratorengruppe gehört. Und UAC werden grundsätzlich weggeklickt. Also alles Gewohnheit...

[apollon77]

Leute ... root Diskussion bitte in nem anderen Thread

[msauer]

@apollon77 sagte

EIne Idee haben wir noch, Installiere die json pakete mal in /opt/iobroker (also nicht wie oben angegeben im /opt/ioborker/node_modules ...). Schau mal ob er es dann "behält".

Vllt will ja npm7 wieder anders behandelt werden.

Zu spät..,,hab komplett neu aufgesetzt und das Backup eingespielt. Schön mit Node 12 und NPM 6. Danach update JSONL und alles fluppt... Vielleicht doch ein kleiner Hinweis ganz oben, weil alles andere lief ja.

Dem Rest der Diskussion enthalte ich mich...wundere mich immer wieder nur...

[crunchip]

@alcalzone sagte in Test Javascript-Adapter 5.0.7 - RULES:

@crunchip Kannst du den CPU-Bedarf ggf. durch stoppen einzelner Adapter eingrenzen?

hab es mal hierher verschoben und bisserl probiert, zumindest sieht man einen "positiven" Einbruch der CPU beim Wled und Linux-control Adapter,
den fully-tablet-control hab ich mal deaktiviert(250mb Ram), gegen fullybrowser (56mb Ram)

Edit: fullytabletcontrol hat sich scheinbar aufgestaut im laufe der Zeit, nach wiederaktivieren 59mb Ram

wieder alles auf Ursprung

[AlCalzone]

@crunchip Ehrlich gesagt sieht linux-control relativ signifikant aus (fast 10% im Mittel). Aktualisiert der viele States oder schreibt der ggf. permanent seine Objekte neu?

[crunchip]

@alcalzone wie bereits erwähnt, hatte ich zuvor states-redis/objects-file und bei objects "writeFileInterval": 3600000 hinterlegt, da ich zuvor herausgefunden hatte, das wled einer der verantwortlichen Adapter ist, für das ständige neu schreiben der object.json,
seit dem lief alles sehr ruhig und die cpu lag im schnitt bei 15%.
Durchs ändern auf jsonl, stieg somit die cpu um mehr als das doppelt an, auf fast 35% im Scnitt.

dann kam das Phänomen mit den Rules dazu, was die Cpu nochmal um 10% ansteigen lies. ( was aktuell jedoch wieder zurück ging, nachdem kein Rules script mehr vorhanden ist)

richtig, linux control werden Massen an state's aktualisiert, weil ich dummerweise bei service nichts eingetragen habe und dadurch alle services einer angelegten Maschine hinterlegt werden, somit komme ich auf eine Gesamtanzahl von rund 10000 states, die im 60 sec intervall aktualisiert werden.
Müsste ich also ändern in der instanz und nur explizite services auswählen, die ich haben möchte und den Rest löschen.

Dennoch bleibt aber der massive CPU Unterschied von redis zu jsonl mit aktueller Konstellation.

Ich habe auch noch weitere Adapter mit sehr vielen state's wie z.b.
unifi, sourceanalytics, sonoff, coronavirus-statistics, daswetter

daswetter habe ich z.b schon seit nem dreiviertel Jahr deaktiviert, da es ebenfalls für einen enormen CPU Anstieg gesorgt hatte.

Edit:
Habe jetzt die services iin der Instanz angepasst, durch speichern und schließen der Instanz, werden die "überflüssigen" Datenpunkte automatisch gelöscht. Dabei ist der simple api mehrmals abgestürzt. Das Problem kenne ich schon länger, bisher konnte mir aber niemand eine Antwort darauf geben, warum das passiert.
Nutze daher dies sogleich, es hier nochmal zu erwähnen, das dies hin und wieder passiert, wenn man, ich nenne es mal "zu viele Datenpunkte auf einmal löscht". siehe Log, das ganze ist insgesamt dreimal passiert.
Gegebenenfalls kann ich auch diesbezüglich einen neuen Thread eröffnen.

host.IoBroker	2021-03-03 23:01:44.496	info	instance system.adapter.simple-api.0 started with pid 12996
host.IoBroker	2021-03-03 23:01:22.611	info	instance system.adapter.weatherunderground.0 terminated with code 0 (NO_ERROR)
host.IoBroker	2021-03-03 23:01:14.391	info	Restart adapter system.adapter.simple-api.0 because enabled
host.IoBroker	2021-03-03 23:01:14.389	error	instance system.adapter.simple-api.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
host.IoBroker	2021-03-03 23:01:14.388	error	Caught by controller[0]: at processTicksAndRejections (internal/process/task_queues.js:97:5)
host.IoBroker	2021-03-03 23:01:14.387	error	Caught by controller[0]: at Immediate.<anonymous> (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/@iobroker/db-objects-jsonl/node_modules/@iobroker/db-objects-redis/lib/objects/ob
host.IoBroker	2021-03-03 23:01:14.386	error	Caught by controller[0]: TypeError: Cannot read property 'common' of null
host.IoBroker	2021-03-03 23:01:14.383	error	Caught by controller[0]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejecte
simple-api.0	2021-03-03 23:01:13.793	info	(31766) terminating with timeout
simple-api.0	2021-03-03 23:01:12.290	warn	(31766) Terminated (UNCAUGHT_EXCEPTION): Without reason
simple-api.0	2021-03-03 23:01:12.283	info	(31766) terminating
simple-api.0	2021-03-03 23:01:12.280	info	(31766) terminating http server on port 8087
simple-api.0	2021-03-03 23:01:12.122	error	(31766) Cannot read property 'common' of null
simple-api.0	2021-03-03 23:01:12.121	error	at processTicksAndRejections (internal/process/task_queues.js:97:5)
simple-api.0	2021-03-03 23:01:12.121	error	at Immediate.<anonymous> (/opt/iobroker/node_modules/iobroker.js-controller/node_modules/@iobroker/db-objects-jsonl/node_modules/@iobroker/db-objects-redis/lib/objects/objectsInRedisClient.js:3607
simple-api.0	2021-03-03 23:01:12.121	error	(31766) TypeError: Cannot read property 'common' of null
simple-api.0	2021-03-03 23:01:12.084	error	(31766) unhandled promise rejection: Cannot read property 'common' of null
simple-api.0	2021-03-03 23:01:12.053	error	(31766) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
host.IoBroker	2021-03-03 23:00:26.927	info	instance system.adapter.ical.0 terminated with code 0 (NO_ERROR)
host.IoBroker	2021-03-03 23:00:26.089	info	instance system.adapter.linux-control.0 started with pid 12441
host.IoBroker	2021-03-03 23:00:23.762	info	instance system.adapter.linux-control.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
host.IoBroker	2021-03-03 23:00:22.769	info	stopInstance system.adapter.linux-control.0 send kill signal
host.IoBroker	2021-03-03 23:00:22.576	info	stopInstance system.adapter.linux-control.0 (force=false, process=true)

[AlCalzone]

@crunchip sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:

für das ständige neu schreiben der object.json,
seit dem lief alles sehr ruhig und die cpu lag im schnitt bei 15%.
Durchs ändern auf jsonl, stieg somit die cpu um mehr als das doppelt an, auf fast 35% im Scnitt.

Das macht für mich Sinn. JSONL merkt sich jede Änderung und dedupliziert dann erst beim Komprimieren. Das heißt aber auch, dass jede dieser Objekt-Änderungen ein JSON.stringify verursacht, dessen Ergebnis dann bis zum nächsten Schreibvorgang im Puffer landet. Wenn das ständig passiert, erzeugt das schon ordentlich Last, da Objekte deutlich mehr Arbeit fürs stringify bedeuten als einfache States.
objects-file hat die unnötigen Änderungen einfach im Speicher überschrieben und dann einmal beim Rausschreiben stringified.
Ggf. könnte hier auch noch ein wenig schlauer gearbeitet werden - ich mach mir mal ein Issue zum Experimentieren.

Wäre ggf. dennoch einen Versuch wert, die Verursacher mal etwas zu gängeln, das dauerhafte Schreiben abzustellen.

[MalleRalle]

Moin @ All
Bevor ich das mal teste.
Wie wird die Datenbank denn gesichert?
Wird die bei einem normalen Backup z.B. über Backitup mit gesichert?

[apollon77]

@malleralle Ja

[crunchip]

@alcalzone sagte in EXPERIMENTELL: JsonL Datenbank für js-controller:

Ggf. könnte hier auch noch ein wenig schlauer gearbeitet werden - ich mach mir mal ein Issue zum Experimentieren.

Gibt es schon neue Erkenntnisse/Fortschritte?

[apollon77]

Es gibt ab jetzt den neuen js-controller 3.3 im Latest (https://forum.iobroker.net/topic/44624/js-controller-3-3-jetzt-im-latest) ... Bei Nutzung einer JSONL-Datenbank sollte das Update nach bisherigen Tests problemlos funktionieren ... Falls nicht bitte lasst uns das hier diskutieren.

Bitte in JEDEM FALL ein Backup vorher haben!