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

[Glasfaser]

@thomas-braun

Sieht fast aktuell aus :

SKRIPTV="2023-06-20"; #version of this script

https://github.com/ioBroker/ioBroker/blob/master/diag.sh#L424

[Thomas Braun]

@glasfaser
Ja, das ist aktuell.
Ich bastel gerade noch an einem 'nodeFall'-Aufräumskript.

[Glasfaser]

@thomas-braun sagte in iob diag - Skript:

'nodeFall'-Aufräumskript.

Meinst du sowas ... in der Art :

npm dedupe

https://typedigital.de/blog/npm-cli-tricks

[Thomas Braun]

@glasfaser

Nee, hab die Nase voll vom nodejs gerade ziehen. Ich versuche die üblichen Fälle von 'irgendwie ins System geprügelt' und/oder nicht fähig eine Ziffer in einer Datei auszutauschen in einem Skript zu heilen.

[Glasfaser]

@thomas-braun sagte in iob diag - Skript:

'irgendwie ins System geprügelt' und/oder nicht fähig eine Ziffer in einer Datei auszutauschen
in einem Skript

OT :

Du kannst ja ... beim "Haifisch" mal schauen vielleicht hat er sowas :joy: :: :sunglasses:

ach nee die kommen hier immer hin .

SORRY .. konnte ich mir nicht verkneifen :)

[Thomas Braun]

Ich habe mal einen Versuch gestartet eine verbogene nodejs-Installation wieder gerade zu biegen und auch ein Update auf nodejs 18 kann man jetzt damit versuchen.
Die Abfrage ob die Installation gefixt werden soll kommt auch nur bei einer erkannten schiefen Ausgangslage, da muss man ggf. zum testen selber gegen die node-Installation treten und die 'kaputt' machen.
Zum Beispiel so:

sudo touch /usr/local/bin/nodejs
sudo chmod +x /usr/local/bin/nodejs

Der Code ist aber offengesagt noch etwas unfertig, also nur für Wagemutige!

(Backup der nodesource.list irgendwo anders parken als in /etc/apt/sources.list.d ist dringend angeraten!)

Docker und alles was kein apt an Bord hat bleibt außen vor.
LXC sollten aber funktionieren. Auf meinem Debian 'Trixie' (Testing) läuft es aber soweit ich das testen konnte.

[Thomas Braun]

Hab heute noch was weitergecodet, jetzt dürften auch Downgrades von höheren nodejs-Versionen auf den jeweils empfohlenen Zweig funktionieren.

Vielleicht sollte man den Code aber aus iob diag heraunehmen und in ein eigenes Skript auslagern? iob nodefix oder so?
Denn eigentlich wollte ich mit dem diag wirklich nur den Zustand des Systems diagnostizieren, nichts fixen.

[Glasfaser]

@thomas-braun

Habe mal quer rübergeschaut .

iob stop
echo "Waiting for ioBroker to shut down - Give me a minute..."
iob stop

in ein eigenes Skript auslagern?

dann mußt du es wieder für Container anpassen ;) ....:ghost:

pkill -u iobroker

dann aber , muß danach der Container neu gestartet werden .. also nicht mit "iob start "

[Thomas Braun]

@glasfaser

Das ist der Part, den ich nicht testen kann. Hatte an pkill bei Containern ehrlich gesagt gar nicht gedacht.
Den Docker hab ich aber schon gleich von vorneherein ausgeschlossen.

[Glasfaser]

@thomas-braun sagte in iob diag - Skript:

ehrlich gesagt gar nicht gedacht.

Ich würde es nicht mit einem Script machen ... du siehst ja selber was so andere ........ daraus machen .

Meine Meinung !

[Thomas Braun]

@glasfaser

Ich kenne das ja nur zu gut.
Die ganz verworrenen Installationen bekommst du damit auch nicht in den Griff.

Aber die einfachen Fälle wie falsche Pfade usw. schon.

[Thomas Braun]

@glasfaser

Für Container:

if [ "$SYSTDDVIRT" != "" ]; 
then
pkill -u iobroker;
else
iob stop;
fi;

[Glasfaser]

@thomas-braun sagte in iob diag - Skript:

Die ganz verworrenen Installationen bekommst du damit auch nicht in den Griff.

richtig ... dann ist er root und ....

@thomas-braun sagte in iob diag - Skript:
iob nodefix oder so?

dann würde ich eine Sperre dazu einbauen.

Aber .. darüber kann man hier ein Buch sreiben ;)

[Thomas Braun]

@glasfaser

Restart des Containers geht nicht per skript, vermute ich. Muss von außen angestoßen werden?

                if [ "$SYSTDDVIRT" != "" ]; then
                        echo "Please restart your container";
                else
                        iob restart;
                fi;

[Thomas Braun]

@glasfaser sagte in iob diag - Skript:

richtig ... dann ist er root und ....

iob diag hat jetzt so eine Sperre. Kannst du als root nicht mehr so einfach aufrufen. Außer du dockerst da herum. Das hab ich ausgenommen.

[Glasfaser]

@thomas-braun sagte in iob diag - Skript:

Restart des Containers geht nicht per skript

doch so z.b.

https://github.com/buanet/ioBroker.docker/blob/47bccc997a84b481a05d6234ebe9283e1f624e03/debian/scripts/maintenance.sh#L154

[Thomas Braun]

@glasfaser

:-) Ich nehme einen PR dazu an...

[Thomas Braun]

@glasfaser

Hoppala...

pkill: killing pid 2574512 failed: Operation not permitted
pkill: killing pid 2631680 failed: Operation not permitted
pkill: killing pid 2631708 failed: Operation not permitted
pkill: killing pid 2631733 failed: Operation not permitted
pkill: killing pid 2631769 failed: Operation not permitted
pkill: killing pid 2631785 failed: Operation not permitted
pkill: killing pid 2631797 failed: Operation not permitted
pkill: killing pid 2631839 failed: Operation not permitted
pkill: killing pid 2631856 failed: Operation not permitted
pkill: killing pid 2631879 failed: Operation not permitted
pkill: killing pid 2631971 failed: Operation not permitted
pkill: killing pid 2632010 failed: Operation not permitted
pkill: killing pid 2632059 failed: Operation not permitted
pkill: killing pid 2632090 failed: Operation not permitted
pkill: killing pid 2632134 failed: Operation not permitted
pkill: killing pid 2632163 failed: Operation not permitted
pkill: killing pid 2632196 failed: Operation not permitted
pkill: killing pid 2632265 failed: Operation not permitted
pkill: killing pid 2632307 failed: Operation not permitted
pkill: killing pid 2632326 failed: Operation not permitted
pkill: killing pid 2632526 failed: Operation not permitted
pkill: killing pid 2632640 failed: Operation not permitted
pkill: killing pid 2632651 failed: Operation not permitted
pkill: killing pid 2632723 failed: Operation not permitted
pkill: killing pid 2632761 failed: Operation not permitted
pkill: killing pid 2632806 failed: Operation not permitted
pkill: killing pid 2632884 failed: Operation not permitted
pkill: killing pid 2633075 failed: Operation not permitted
pkill: killing pid 2633214 failed: Operation not permitted
pkill: killing pid 2633234 failed: Operation not permitted
pkill: killing pid 2633275 failed: Operation not permitted
pkill: killing pid 2633299 failed: Operation not permitted
pkill: killing pid 2633324 failed: Operation not permitted
pkill: killing pid 2633352 failed: Operation not permitted
pkill: killing pid 2633420 failed: Operation not permitted
pkill: killing pid 2633714 failed: Operation not permitted
pkill: killing pid 2636818 failed: Operation not permitted
pkill: killing pid 2636865 failed: Operation not permitted

Da muss ich bei der Weiche nochmal schauen...

[Homoran]

@thomas-braun Wenn ich das quer durch's Forum richtig verfolgt habe, waren ältere Versionen von nicht mehr unterstützen Node-Versionen der Auslöser für diese sinnvolle Erweiterung/Ergänzung.
Was passiert denn wenn ein User mit node 6 (oder realistischer mit node 14) jetzt iob diag aufruft?

[mcm1957]

@thomas-braun said in iob diag - Skript:

Hab heute noch was weitergecodet, jetzt dürften auch Downgrades von höheren nodejs-Versionen auf den jeweils empfohlenen Zweig funktionieren.

Vielleicht sollte man den Code aber aus iob diag heraunehmen und in ein eigenes Skript auslagern? iob nodefix oder so?
Denn eigentlich wollte ich mit dem diag wirklich nur den Zustand des Systems diagnostizieren, nichts fixen.

Ja
Eine Trennung würd ich als gut empfinden.
Warum? Ich würde gerne eine Diagnose möglichkeit gaben (iob_diag) die garantiert mal nichts verändert.
Ob ich dann fixen will und wie sol meine Entscheidung sein. Diag soll da zunäcgst mal nix ändern. Auch nicht irrtümlich.
Minimal muss ein Prompt mit Default "nicht ändern" das absichern. Besser wär aber ein extra aufruf vor dem man nach möglichkeit noch mal ein gesammt backup nachen sollte.

Mcm