Beta Test js-controller 3.2.x auf GitHub

[lobomau]

@apollon77 muss ich wenn ich auf js-controller 3.1.6 zurückgehe auch den admin downgraden?
3.1.6 läuft bereit, aber meine Admin Probleme bleiben bestehen.

[Jan1]

@lobomau
Nein, wobei Admin 3.1.6? Ist das der aktuelle aus dem default REPO? Ist ja welten hinter dem aktuellen aus beta.

[lobomau]

@jan1 nee, admin ist gerade 4.2.1.
JS ist 3.1.6.

[Jan1]

@lobomau
Ok, ist noch früh
Den JS brauchst aber auuch nicht downgraden, da der läuft, außer die Unschönheit mit dem Adapter Update. Das kannst aber sehr einfach mit Klick oben auf das Fähnchen übergehen.

[lobomau]

@jan1 mein System scheint da speziell (Proxmox Debian 10 Container). Da ging einiges nicht mehr (Adapter wurden nicht angezeigt, Updates der Adapter nicht möglich, einige Abstürze über Nacht (RAM und CPU bis 100%...). Ich habe einige Adapter ausgestellt und gestern sogar ein ganz frisches System erstellt.
Nun bin ich wieder auf ein Backup vom 4. Januar.

Bei Gegebenheit versuche ich es mal mit einem Testsystem wieder nachzustellen. Leider bin ich mit meiner 120 GB SSD auch etwas begrenzt für weitere Testcontainer.

[Jan1]

@lobomau
Der Grund warum ich mir Proxmox nie antun würde. Die meisten Probleme die ich im Forum lese sind irgendwelche nicht native Aufbauten

[ChrisXY]

Radar2 macht bei mir:

radar2.0	2021-01-14 10:50:23.109	warn	(3317) Uncaught Exception: bind EACCES 0.0.0.0:67
radar2.0	2021-01-14 10:50:23.108	error	(3317) Error: bind EACCES 0.0.0.0:67 at dgram.js:337:20 at processTicksAndRejections (internal/process/task_queues.js:81:21)
radar2.0	2021-01-14 10:50:23.107	error	(3317) uncaught exception: bind EACCES 0.0.0.0:67

[coyote]

@chrisxy mach mal:

sudo setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which arp-scan`)
sudo setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which node`)
sudo setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which arp`)
sudo setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which hcitool`)
sudo setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which hciconfig`)
sudo setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which l2ping`)

dann sollte er wieder tun

[apollon77]

@lobomau Ne Admin ist backward-compatible

[apollon77]

@jan1 Hm ... Ich hab ein Proxmox HA Cluster am laufen und mehrere test und production Container und VMs ... also ich habe keinerlei Probleme. Also sorry kann ich nicht bestätigen

[apollon77]

@chrisxy Der offizielle weg ist "iobroker fix"

[Kueppert]

@apollon77 ich hatte eben ein seltsames Verhalten nachdem ich SourceAnalytix über die Katze von GIT aktualisiert habe:
Auslastung ging hoch auf 120%, immer weider die selbe Fehlermeldung im LOG (anbei).
Dann haben sich alle Adapter neu gestartet, Auslastung runter auf 85%.
Danach haben sich die WOgen geglättet und IOB lief wieder auf 25% (wie üblich).

Ich nutze den Controller 3.2.0-6:

The promise rejected with the reason:
2021-01-14 14:58:39.900  - error: host.ioBroker2 Caught by controller[5]: Error: Connection is closed.
2021-01-14 14:58:39.900  - error: host.ioBroker2 Caught by controller[5]:     at Redis.sendCommand (/opt/iobroker/node_modules/ioredis/built/redis/index.js:607:24)
2021-01-14 14:58:39.900  - error: host.ioBroker2 Caught by controller[5]:     at Redis.publish (/opt/iobroker/node_modules/ioredis/built/commander.js:111:25)
2021-01-14 14:58:39.900  - error: host.ioBroker2 Caught by controller[5]:     at StateRedisClient.pushMessage (/opt/iobroker/node_modules/@iobroker/db-states-redis/lib/states/statesInRedisClient.js:898:31)
2021-01-14 14:58:39.900  - error: host.ioBroker2 Caught by controller[5]:     at Sourceanalytix.sendToHost (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:5660:31)
2021-01-14 14:58:39.900  - error: host.ioBroker2 Caught by controller[5]:     at /opt/iobroker/node_modules/iobroker.js-controller/lib/tools.js:1619:16
2021-01-14 14:58:39.901  - error: host.ioBroker2 Caught by controller[5]:     at new Promise (<anonymous>)
2021-01-14 14:58:39.901  - error: host.ioBroker2 Caught by controller[5]:     at Sourceanalytix.sendToHostAsync (/opt/iobroker/node_modules/iobroker.js-controller/lib/tools.js:1618:16)
2021-01-14 14:58:39.901  - error: host.ioBroker2 Caught by controller[5]:     at Sourceanalytix.registerNotification (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:5677:24)
2021-01-14 14:58:39.901  - error: host.ioBroker2 Caught by controller[5]:     at exceptionHandler (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:8457:28)
2021-01-14 14:58:39.901  - error: host.ioBroker2 Caught by controller[5]:     at process.<anonymous> (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:8477:45)
2021-01-14 14:58:39.901  - error: host.ioBroker2 Caught by controller[5]: 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(). 

[apollon77]

@kueppert Fixen wir in der nächsten Version vom controller. Effektiv kann das passieren wenn Adapter beendet werden und da Dinge später mit der DB gemacht werden aber die schon disconnected ist ... dann gibts Error-Loop ... wir machen das ein bissl relaxed

[Jan1]

@apollon77 said in Beta Test js-controller 3.2.x auf GitHub:

@jan1 Hm ... Ich hab ein Proxmox HA Cluster am laufen und mehrere test und production Container und VMs ... also ich habe keinerlei Probleme. Also sorry kann ich nicht bestätigen

Ich bin mir auch sicher, dass Du weißt was Du tust und weißt was zu tun ist, wenn was nicht läuft.

[Homoran]

@jan1 Das "Problem" ist nicht die Benutzung von proxmox, sondern das fehlende Wissen bei der Nutzung von Containern innerhalb von Proxmox.
mit einer VM innerhalb von Proxmox gibt es eigentlich nie Probleme.

[Kueppert]

Genau so ist es...VM ist ja fast wie nen eigenständiger Rechner...Container hab ich mich mal eingelesen, war mir aber zu abweichend vom Standard-Linux und zu zeitaufwendig, mich damit zu beschäftigen.
Einfach ne VM, gut ist

[Jan1]

@homoran
Da müssen wir nicht drüber diskutieren, ist bekannt, dass das eigentliche Problem an der Tastatur sitzt.
Es ist eher das Problem, dass eben User sich hier was zusammenbauen weil es bei anderen auch läuft, aber nicht wissen was sie da tun und das zeitgleich mit dem Einstieg in IOBROKER.

So hast gleich ein paar Baustellen in einer und ohne wirkliches Wissen dazu ist es eben recht schwer.

[Thomas Braun]

@jan1 said in Beta Test js-controller 3.2.x auf GitHub:

zeitgleich mit dem Einstieg in IOBROKER.

Und einem Einstieg in Linux auf CLI-Ebene. Kommt als weitere Baustelle neben Proxmox und dem ioBroker noch dazu.

[lobomau]

@thomas-braun @Jan1 ihr habt erstmal Recht. Ich werde nun auch (wieder) auf eine VM umstellen.

Nichtsdestotrotz muss ich sagen, dass ich ioBroker schon Monate (Jahre?) so hab laufen lassen und natürlich etliche js-controller Updates so durchgeführt habe und nie ein Problem hatte. Leider werde ich die Ursache auch wahrscheinlich nicht mehr erfahren. Aber mal schauen... vielleicht kommt das Problem ja wieder... dann lag das Problem ganz woanders....
Wichtig ist zu wissen, dass es bei euch ohne Probleme läuft.

[apollon77]

@lobomau said in Beta Test js-controller 3.2.x auf GitHub:

der werde ich die Ursache auch wahrscheinlich nicht mehr erfahr

DOCH die Ursache ist ermittelt und mit dem nächsten controller pre-release gefixt (also wenn es das bei dir auch ist was wir jetzt gefunden haben, was ich aber denke das es wahrscheinlich ist)