js-controller 3.2 jetzt im Latest!

[fastfoot]

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

@thomas-braun Neee ... bzw ... ja die erste Anleitung hatte es falsch. Der Redis Simulator in der File DB hat ein neues kommando und es hagelt Fehler wenn der nicht zuerst da ist

das habe ich jetzt 5 mal gelesen und jedesmal weniger verstanden. Wie ist denn jetzt die Reihenfolge konkret mit 3.2.x?

[PrinzEisenherz1]

@fastfoot
Du lässt den Master laufen! Dann den/die Slaves mit iobroker stop anhalten.
Den/die Slaves mit

iobroker upgrade self

upgraden.
Dann den/die Slaves noch nicht starten!
Dann machst du auf dem Master ein

iobroker stop

Dann updatest du mit

iobroker upgrade self

den Master.
Im Anschluss am Master ein

iobroker restart

Dann wartest Du etwas und dann den/dem Slave(s) ein

iobroker restart

Dann ist alles schick

[apollon77]

@prinzeisenherz1 NEEEEEEEE GENAU ANDERS RUM!!!!

Diesmal ZUERST den Master machen, DANACH die Slaves!

[amg_666]

@apollon77 Dann sollte das aber auch im Hinweistext so stehen. Wenn ich im Admin auf Hosts gehe und dann z.B. bei meinem Master auf das "Upgrade" Symbol klicke dann kommt ein Textfenster in dem steht
...
Für ein Update von js-controller 1.x auf 2.x bitte in jedem Fall die Informationen unter https://forum.iobroker.net/topic/26759/js-controller-2-jetzt-für-alle-im-stable lesen und beachten!
Ansonsten bitte bei einem Update von Master-Slave-Systemen die Slaves zuerst aktualisieren und den Master als letztes!
...

Also doch erst Slave dann Master ????

[PrinzEisenherz1]

@amg_666 @apollon77 Lach...sorry, jetzt war ich falsch! Mea culpa! Vergesst was ich geschrieben hab!
Ich geh besser schlafen.

[apollon77]

So, alle miteinander, wir haben die letzten Tage noch kleinere Issues und Optimierungen gesammelt und diese kommen jetzt demnächst als 3.2.8 ins Latest:

3.2.8 (2021-01-21)

• (Apollon77) fix reading of certificates if the given certificates are files
• (Apollon77) add error handling when let's encrypt configuration contains invalid domain names and other cases to allow still access to the adapter if possible
• (foxriver76) fix compact mode cli commands
• (AlCalzone) Support more Github URL formats for iobroker url command
• (foxriver76) replace exit codes in setup js with named constants
• (foxriver76) add adapter method getUserId
• (Apollon77) add seq logging support to js-controller
• (Foxriver76) Harmonize username handling between admin and js-controller by transforming the object id to lowercase. With this user names will be treated case insensitive from now on!

[apollon77]

@amg_666 Naja es steht aktuell hier oben im Thread ... der zur aktuellsten Version ... Admin updaten wir noch sobald es ins Stable geht!

[fastfoot]

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

Also doch erst Slave dann Master ????

• für Hosts bis 3.1.6 Slave --> Master
• für Hosts ab 3.2.x Master --> Slave

wenn das jetzt noch falsch ist, dann liegt das nicht an mir

lag doch an mir, tatsächlich sollte man den ersten Post lesen (zur Not mehrfach, musste ich auch, obwohl es eig. klar da steht)

[apollon77]

@fastfoot jain oben im ersten post steht es an sich drin

[Feuersturm]

@apollon77 Update auf 3.2.8 lief ohne Probleme und alle Instanzen sind sauber gestartet

[amg_666]

@apollon77 ok, sollte man vielleicht vorher lesen

So, ich hab 3* Raspi 3b+, npm 6.14.8, node.js v12.19.0, auf dem MASTER hab ich jetzt Upgrade auf 3.2.7 durchgeführt, sieht gut aus. Die Slaves stehen noch auf 3.1.6, ich werd die jetzt nach und nach umstellen.

Update: die 3.2.8 wurde mir vorhin noch nicht angezeigt und ich habe jetzt einen Slave upgedatet, der hat jetzt die 3.2.8, läuft offensichtlich mit einem Master mit 3.2.7 und ich habe ja jetzt den Slave zuerst upgedated

[apollon77]

@amg_666 Ja 3.2 ist untereinander kompatibel.

[amg_666]

@apollon77 Ich hatte ursprünglich den Fehler gemeldet bei klf200 und co. Nach Upgrade auf 3.28 in der richtigen Reihenfolge (erst Master dann Slave) läuft bei mir alles stabil.

[Neuschwansteini]

@apollon77 3.2.8 absolut problemlos hier

[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