js-controller 4.0.x jetzt für alle User im STABLE!

foxriver76

@rene55 Der Admin wird in der Version installiert wie er im Backup vorhanden war. So wird sichergestellt dass du 1 zu 1 die selbe Installation wie im Backup bekommst, js-controller ausgenommen wenn du mit force arbeitest. Weiß nicht was da nichts für schwache Nerven ist, ein Backup schiebt dich im Besten Fall 1 zu 1 zurück zu einem früheren Zeitpunkt.

Rene55

@foxriver76 Danke für die erklärenden Worte. Ich hatte mir nur die Consolenausgaben angesehen und war etwas überrascht. Aber nach der Erklärung wird's verständlich. Der ioB hat jetzt alle Adapter nachgezogen und alles scheint zu laufen. Also auch von mir, Daumen hoch für den js-Controller 4.x.

wendy2702

Hi,

ich habe mit dem JS4.0.15 Problem mit dem automatischen Stoppen der Adapter. Aktuell aufgefallen beim birthdays Adapter. Wenn ich hier zum Beipiel das loglevel ändere wird die Instanz bzw. der Prozess scheinbar nicht gestoppt was dann das zur Folge hat:

2022-02-28 09:53:31.901  - debug: birthdays.1 (13847) filling next with 11 days left
2022-02-28 09:53:31.915  - debug: birthdays.1 (13847) filling nextAfter with 26 days left
2022-02-28 09:53:46.434  - info: host.iobroker stopInstance system.adapter.birthdays.1 (force=false, process=true)
2022-02-28 09:53:46.434  - info: host.iobroker stopInstance canceled schedule system.adapter.birthdays.1
2022-02-28 09:53:49.577  - info: host.iobroker instance scheduled system.adapter.birthdays.1 0 0 * * *
2022-02-28 09:53:49.606  - info: host.iobroker instance system.adapter.birthdays.1 started with pid 13871
2022-02-28 09:53:50.445  - error: birthdays.1 (13871) birthdays.1 already running
2022-02-28 09:53:50.447  - warn: birthdays.1 (13871) Terminated (ADAPTER_ALREADY_RUNNING): Without reason
2022-02-28 09:53:51.069  - error: host.iobroker instance system.adapter.birthdays.1 terminated with code 7 (ADAPTER_ALREADY_RUNNING)
2022-02-28 09:54:15.748  - info: host.iobroker "system.adapter.birthdays.1" disabled
2022-02-28 09:54:15.749  - info: host.iobroker stopInstance system.adapter.birthdays.1 (force=false, process=false)
2022-02-28 09:54:15.750  - info: host.iobroker stopInstance canceled schedule system.adapter.birthdays.1
2022-02-28 09:54:22.474  - info: host.iobroker "system.adapter.birthdays.1" enabled
2022-02-28 09:54:22.474  - info: host.iobroker stopInstance system.adapter.birthdays.1 (force=false, process=false)
2022-02-28 09:54:25.615  - info: host.iobroker instance scheduled system.adapter.birthdays.1 0 0 * * *
2022-02-28 09:54:25.644  - info: host.iobroker instance system.adapter.birthdays.1 started with pid 13916
2022-02-28 09:54:26.630  - error: birthdays.1 (13916) birthdays.1 already running
2022-02-28 09:54:26.631  - warn: birthdays.1 (13916) Terminated (ADAPTER_ALREADY_RUNNING): Without reason
2022-02-28 09:54:27.252  - error: host.iobroker instance system.adapter.birthdays.1 terminated with code 7 (ADAPTER_ALREADY_RUNNING)

Ist das noch ein Problem vom Controller oder Adapter oder ganz was anderes?

arteck

@wendy2702 sagte in js-controller 4.0.x jetzt für alle User im STABLE!:

birthdays Adapter

der läuft doch über cronjob oder ?

wendy2702

@arteck Ja.

Der Prozess bleibt aber auch aktiv wenn ich die Instanz im Admin Stoppe

PatrickFro

Moin,

ich schätze, mein Fehler hat auch mit dem js-controller zu tun.

Ich musste einen iobroker neu installieren. Dieses habe ich nun 3 Mal durchgeführt, immer selbes Ergebnis:

Im Log:

admin.0
2022-02-28 10:34:22.677	warn	Cannot update news: getaddrinfo EAI_AGAIN iobroker.live
admin.0
2022-02-28 10:34:22.672	warn	Cannot update rating: getaddrinfo EAI_AGAIN rating.iobroker.net
admin.0
2022-02-28 10:05:23.273	warn	Active repository "stable cannot be read
admin.0
2022-02-28 10:05:23.272	warn	Repository cannot be read: Active repo - stable

Zudem, klicke ich auf Benutzer, erscheint dieses:

Ich habe sowohl die automatische als auch die manuelle Installation durchgeführt, habe neues Linux genutzt, keine andere Verwendung des Raspis gehabt.

Thomas Braun

@patrickfro

Schaut nach Netzwerkproblemen aus.

PatrickFro

@thomas-braun Ich habe den Adminadapter mal downgegradet, funktionierte. Eine neuere Version wurde mir dann auch direkt angeboten. Somit war dieses Problem vielleicht auch nur kurzfristig

Zumindest das untere Problem haben laut Github auch andere.

PatrickFro

Noch ein Test: Ich habe ein Backup eines anderen Raspis mit IoBroker auf den neuen aufgespielt, selbes Verhalten mit Absturz bei klick auf "Benutzer"

apollon77

@patrickfro Also das sind DNS Lookup issues ... es gab nen anderen User der auch berichtet hat das das bei einem Reboot manchmal passiert.. Wenn er danach Adapter manuell restartet passiert es nicht. Das wäre dann irgendwie ein Timeing issue beim Boot und verfügbarkeit vom DNS Dienst ... müsste man aber getrennt anschauen weil dafür kann der Controller nichts.

Auch das Standard systemd service hat "after network.target" drin, also sollte an sich alles passen ... keine Ahnung was da besonders ist.

Wäre für mich langsam wert einen eigenen Thread zu haben wo man dem auf den Grund geht

apollon77

@wendy2702 Naja, da kein anderer Schedule Adapter scheinbar isues macht wäre ich erstmal beim Adapter und nicht beim Controller Gff mal issue beim Adapter öffnen.

apollon77

@patrickfro Und für das Admin issue bitte dort ein Issue öffnen

PatrickFro

@apollon77 Danke für die Info. Letztlich ist das für mich kein Problem, da alles trotzdem funktioniert und bisher bei jeder Installation nur jeweils einmal bzw. bei Neustart angezeigt wurde.

Das zweite Problem (das Bild) ist aber was anderes. Kann dieses denn auch mit dem js-Controller zu tun haben? Gerade habe ich zum weiteren Test auch eine neue VM in Proxmox angelegt und IoBroker installiert. Auch hier habe ich die Abstürze beim Reiter Benutzer. Es ist somit nichts Raspi-spezifisches.

PatrickFro

@apollon77 Ok, also eher Admin. Dafür sind schon mehrere Threats geöffnet. Dann werde ich mal abwarten, was da passiert und leider bis dahin im Keller keine Alarmanlage haben.

wendy2702

@apollon77 sagte in js-controller 4.0.x jetzt für alle User im STABLE!:

@wendy2702 Naja, da kein anderer Schedule Adapter scheinbar isues macht wäre ich erstmal beim Adapter und nicht beim Controller Gff mal issue beim Adapter öffnen.

Scheinbar war das schon bekannt und es gab gerade eine neue Version. Mal testen und beobachten.

padrino

So, wollte eigentlich erstmal auf 3.3 upgraden, hab aber nicht mitbekommen, dass V4 im Stable ist... Also hat das System automatisch versucht V4 zu installieren.
Ergebnis, mein iob ist hin.
Installation spuckte nach gut 5 Minuten folgendes aus:

pi@raspberrypi:/opt/iobroker $ iobroker upgrade self
Update js-controller from @3.1.6 to @4.0.15
NPM version: 6.14.15
npm install iobroker.js-controller@4.0.15 --loglevel error --unsafe-perm --prefix "/opt/iobroker" (System call)
In file included from ../../nan/nan.h:56,
                 from ../src/unix_dgram.cc:5:
/home/iobroker/.cache/node-gyp/12.22.6/include/node/node.h:736:43: warning: cast between incompatible function types from ‘void (*)(v8::Local<v8::Object>)’ to ‘node::addon_register_func’ {aka ‘void (*)(v8::Local<v8::Object>, v8::Local<v8::Value>, void*)’} [-Wcast-function-type]
       (node::addon_register_func) (regfunc),                          \
                                           ^
/home/iobroker/.cache/node-gyp/12.22.6/include/node/node.h:770:3: note: in expansion of macro ‘NODE_MODULE_X’
   NODE_MODULE_X(modname, regfunc, NULL, 0)  // NOLINT (readability/null_usage)
   ^~~~~~~~~~~~~
../src/unix_dgram.cc:404:1: note: in expansion of macro ‘NODE_MODULE’
 NODE_MODULE(unix_dgram, Initialize)
 ^~~~~~~~~~~
 Objects 127.0.0.1:59278 Error from InMemDB: Error: GET-UNSUPPORTED for namespace cfg.: Data=["meta.objects.features.useSets"]
 States 127.0.0.1:60766 Error from InMemDB: Error: GET-UNSUPPORTED for namespace meta.: Data=["meta.states.protocolVersion"]
 Objects 127.0.0.1:59278 Error from InMemDB: Error: GET-UNSUPPORTED for namespace cfg.: Data=["meta.objects.protocolVersion"]
 Objects 127.0.0.1:59278 Error from InMemDB: Error: scan NOT SUPPORTED
/opt/iobroker/node_modules/standard-as-callback/built/index.js:6
        throw e;
        ^

ReplyError: Error scan NOT SUPPORTED
    at parseError (/opt/iobroker/node_modules/redis-parser/lib/parser.js:179:12)
    at parseType (/opt/iobroker/node_modules/redis-parser/lib/parser.js:302:14)
Emitted 'error' event on ScanStream instance at:
    at /opt/iobroker/node_modules/ioredis/built/ScanStream.js:38:22
    at tryCatcher (/opt/iobroker/node_modules/standard-as-callback/built/utils.js:12:23)
    at /opt/iobroker/node_modules/standard-as-callback/built/index.js:33:51
    at processTicksAndRejections (internal/process/task_queues.js:97:5) {
  command: {
    name: 'scan',
    args: [ '0', 'MATCH', 'cfg.o.system.host.*', 'COUNT', '250' ]
  }
}
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! iobroker.js-controller@4.0.15 install: `node iobroker.js setup first`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the iobroker.js-controller@4.0.15 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/iobroker/.npm/_logs/2022-02-28T19_25_50_415Z-debug.log
host.raspberrypi Cannot install iobroker.js-controller@4.0.15: 1
pi@raspberrypi:/opt/iobroker $

iobroker start bleibt nun still, sprich admin nicht erreichbar...

gebe ich nur iobroker ein kommt

pi@raspberrypi:/opt/iobroker $ iobroker
internal/modules/cjs/loader.js:818
  throw err;
  ^

Error: Cannot find module '/opt/iobroker/node_modules/iobroker.js-controller/iobroker.js'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:815:15)
    at Function.Module._load (internal/modules/cjs/loader.js:667:27)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12)
    at internal/main/run_main_module.js:17:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

Ich weiß schon, wieso ich normal nach dem Prinzip "never change a running system" handele, denn, wenn wie jetzt was schief geht steht man als noob wie der Ochs vorm Scheunentor.

Thomas Braun

@padrino sagte in js-controller 4.0.x jetzt für alle User im STABLE!:

Ich weiß schon, wieso ich normal nach dem Prinzip "never change a running system" handele

Der dämliche Spruch hat sich jetzt genau in die Situation gebracht.
Je größer die Versionssprünge werfen umso heikler wird das u.U.

iobroker status

sagt? Aber besser in einem eigenen Thread.

padrino

@thomas-braun sagte in js-controller 4.0.x jetzt für alle User im STABLE!:

Der dämliche Spruch hat sich jetzt genau in die Situation gebracht.

Naja, es lief ja vor dem Update... was ja unbestritten ist.

@thomas-braun sagte in js-controller 4.0.x jetzt für alle User im STABLE!:

Je größer die Versionssprünge werfen umso heikler wird das u.U.

Sollte dann nicht der Installer das berücksichtigen und erstmal "klein" updaten, oder einem dazu raten?

Auf jeden Fall, hat mir jetzt ein
npm install iobroker.js-controller@3.3
mir iob wohl erstmal wieder zum Laufen gebracht.

Thomas Braun

@padrino

Dann kannst du ja jetzt das System auf Stand bringen. Ich würde mit nodeJS anfangen und das auf v14 bringen.

apollon77

@padrino Ok, lösung ist sehr einfach: Nicht "iob uplgrade self nehmen" ... ALso fix durchcontroller per npm drüberbügeln

iobroker stoppen
cd /opt/iobroker
npm iobroker.js-controller@4.0.15 --production
iobroker starten

NEWS

js-controller 4.0.x jetzt für alle User im STABLE!

Support us

976
Online

30.5k
Users

76.8k
Topics

1.2m
Posts

NEWS

js-controller 4.0.x jetzt für alle User im STABLE!

Support us

976Online

30.5kUsers

76.8kTopics

1.2mPosts

976
Online

30.5k
Users

76.8k
Topics

1.2m
Posts