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

[MalleRalle]

@apollon77
iobroker fix wirft nach Update auf 3.2.8 diese Meldung aus:

Created /etc/sudoers.d/iobroker
main: line 548: ~/.iobroker/iobroker_completions: No such file or directory
main: line 550: ~/.iobroker/iobroker_completions: No such file or directory
Fixing directory permissions...

[apollon77]

@malleralle Ja ist ein issue im installer/fixer und schon bekannt. Hat mit Controller nichts zu tun. Ist aber nicht wild

[Chaot]

@apollon77
Ich habe diese Warnmeldungen (auch bei anderen Adaptern)

host.ioBroker	2021-01-22 07:07:10.332	info	instance system.adapter.fully-tablet-control.0 terminated with code 156 (START_IMMEDIATELY_AFTER_STOP)
host.ioBroker	2021-01-22 07:07:10.286	info	instance system.adapter.sonoff.0 terminated with code null ()
host.ioBroker	2021-01-22 07:07:10.285	warn	instance system.adapter.sonoff.0 terminated due to SIGTERM
host.ioBroker	2021-01-22 07:07:10.285	info	instance system.adapter.mqtt.0 terminated with code null ()
host.ioBroker	2021-01-22 07:07:10.284	warn	instance system.adapter.mqtt.0 terminated due to SIGTERM

Was ist SIGTERM?

[apollon77]

@chaot Wann genau hast du diese meldung? Beim stoppen des Controllers?

Wenn ja dann ist das normal bzw ok.

Wenn der controller einen Adapter stoppt sagt er ihm er solle sich bitte beenden. Wenn er das in erhalb einer gewissen Zeit nicht tut dann sagt er dem Betriebssystem er das dieses den Prozess beenden sol. Das ist quasi SIGTERM ("Signal Terminate")

[Chaot]

@apollon77 Die kamen jetzt nach dem Update als ich das System wieder hochgefahren habe. Also beim ersten Start.

[apollon77]

@chaot Ok, dann braucht es wohl mehr log. Effektiv heisst das das Irgendjemand die Prozesse gekillt hat ... an sich macht das nur der controller oder dein betriebssystem wenn du "Kill" sagtst oder in low RAM situaitionen oder so. Wenn die Adapter danach neu gestartet wurden alles ok

[Chaot]

@apollon77 Ach, ich denke das hat sich erledigt. Nachdem ich alles nochmal gestartet habe kamen die Meldungen nicht mehr.
Mal Abwarten.

[myssv]

Ich bekomme beim Neustart mit einem Mal folgende Meldungen:

[...]
host.iobroker check instance "system.adapter.fritzdect.0" for host "iobroker",
host.iobroker check instance "system.adapter.fb-checkpresence.0" for host "iobroker",
host.iobroker check instance "system.adapter.tr-064.0" for host "iobroker",
ls: Zugriff auf '/dev/disk/by-id/' nicht möglich: Datei oder Verzeichnis nicht gefunden,
,
ls: Zugriff auf '/dev/disk/by-id/' nicht möglich: Datei oder Verzeichnis nicht gefunden,
,

ioBroker läuft im Docker auf einer Synology

[Josh]

@fastfoot

Also wat nu? Ich lese folgendes:

Bei einem Multi-Host-System, welches auf js-controller 2.2 oder 3.1 läuft ist es beim Update auf Version 3.2 empfohlen, zuerst das Master-System zu aktualisieren. Die Slaves werden danach aktualisiert!

Bei mir lief 3.1.6 und ich wollte auf 3.2.7. Also erst Master dann Slave. Trotzem wurde die Console nicht mehr freigegeben.

Wenn ich aber den Master und den Slave gleichzeitig stoppe, dann beide System update (egal welche Reihenfolge) sollte es doch perfekt sein, oder?

[apollon77]

@myssv bitte echtes log kopieren ... da ist an sich ein Adaptername davor

[apollon77]

@josh Bei einem Slave update muss der master immer laufen (ausser du hast ein redis/redis System). Ich füge es hinzu nochmal zur SIcherheit

[Josh]

@apollon77
Ich habe Redis auf dem Master laufen und den Slave mit dem Redis auf dem Master verbunden (denke ich ...)

Wie mache ich es denn dann?!?!?

[apollon77]

@josh Wenn Du ein Redis/Redis System hast (also beide DBs States und Ibjects auf Redis) dann ist die Reihenfolge komplett schnuppe weil es keinen "iobroker Master" mehr gibt ... der Redis ist "der Master". Reihenfolge in dem Fall egal

[myssv]

@apollon77 Die Meldung kommt an der Konsole, die ich im Portainer sehe

Im ioBroker Log finde ich sie nicht

[Josh]

@apollon77
OK, verstanden. Dann ist es auch egal, wenn ich es so mache, wie es beschrieben ist.

Ich gucke nochmal nach, ob ich beides (States und Objects) verbunden habe. Die Redis-Einrichtung ist schon 'ne ganze Zeit her...

EDIT:
Der Befehl

iobroker multihost status

gibt beim Master folgendes zurück

Multihost discovery server: disabled
Discovery authentication:   enabled
Persistent activation:      disabled
Objects:                    file on 0.0.0.0
States:                     redis on 127.0.0.1

und beim Slave

Multihost discovery server: disabled
Discovery authentication:   enabled
Persistent activation:      disabled
Objects:                    file on 192.168.178.115
States:                     redis on 192.168.178.115

Ist das die von DIr beschriebene redis/redis config?

[Diginix]

@apollon77
Update von 3.1.6 auf 3.2.8 liefert folgende Logeinträge:

2021-01-22 09:59:39.552 - error: web.0 (593419) [LE] {"code":"E_FAIL_DRY_CHALLENGE","context":"cert_renewal","subject":"***.myfritz.net","altnames":["***.myfritz.net"]}
2021-01-22 10:04:06.915 - error: dwd.0 (593900) 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().
2021-01-22 10:04:06.920 - error: dwd.0 (593900) unhandled promise rejection: DB closed
2021-01-22 10:04:06.957 - error: dwd.0 (593900) Error: DB closed
at close (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:179:25)
at Socket. (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:146:20)
at Object.onceWrapper (events.js:421:26)
at Socket.emit (events.js:314:20)
at Socket.EventEmitter.emit (domain.js:483:12)
at TCP. (net.js:675:12)
2021-01-22 10:04:06.958 - error: dwd.0 (593900) DB closed

Port 80 ist bei mir nur für iob auf wenn ich das letsencrypt cert verlängern muss. Sonst ist der anderweitig belegt.
Kommt die Meldung daher?

Die DWD Meldungen sind nur FYI oder relevant?

Und das MaterialUI Frontend kann mit lokaler IP gar nicht mehr aufgerufen werden.

nodejs: 12.20.1
JS-Controller: 3.2.8
dwd: 2.7.2
web: 3.2.3

[apollon77]

@myssv Dann denke ich wäre das eine Frage für buanet :-)

[apollon77]

@josh neeee objects -> file ... also hast du den Objects Server weiterhin vom iobroker "master"

[apollon77]

@diginix Der Fehler von web sollte daher kommen das er certs updaten will aber nicht kann ... Wenn du "auto renewal" aktiviert hast dann solltest du auch "immer" den Port verfügbar haben ... sonst musst du das automatisch update deaktivieren.

dwd: haste mal ganzes log von dem "lauf"?`

[apollon77]

@diginix sagte in js-controller 3.2 jetzt im Latest!:

Und das MaterialUI Frontend kann mit lokaler IP gar nicht mehr aufgerufen werden.

das liegt leider daran das das neue letsencrypt ohne "einmal zertifikate" so reagiert und keine hat. Da ist schon ein Bug offen ... also: lass ihn einmal updaten, dann sollte das wieder gehen