Diskussion zum neuen Installation-Fixer

[bahnuhr]

@paul53 sagte in Diskussion zum neuen Installation-Fixer:

@AlCalzone sagte:

Redis musst du manuell aktivieren mit

Es sei denn, er hat ein älteres Image verwendet.

Also den raspie slave habe ich jetzt ca. 1 Jahre in Betrieb (seit 3/2018)

[Homoran]

@bahnuhr
mit Image oder selbst aufgesetzt?

[bahnuhr]

gute Frage:

Ich glaube ich habe das minimal image genommen und dann smartmeter und mbus nach installiert.

[Homoran]

@bahnuhr

dann war da (vielleicht) noch redis drauf.

Aber beim Anlegen des Multihosts hast du doch sicher das wieder auf file geändert, da dein Notebook kein Redis hat

[AlCalzone]

Ahhh, neue Informationen... Das Problem tritt also nur auf dem Slave im Multihost auf? @wendy2702 Bist du auch auf Multihost unterwegs?

[bahnuhr]

@Homoran sagte in Diskussion zum neuen Installation-Fixer:

Aber beim Anlegen des Multihosts hast du doch sicher das wieder auf file geändert, da dein Notebook kein Redis hat

Rainer,
ich muss leider eingestehen, dass ich nicht weiß wovon du redest (bzgl. redis und file).

Slave: raspi mit smartmeter und mbus
image minimal installiert.
Und dann eingerichtet als slave. läuft seit mehreren Monaten einwandfrei.

Master: win7 Laptop -> auf dem läuft iob
Installiert nach Anleitung (wie auf Homepage iob).
Aber auch das ist schon 2 Jahre her.

[wendy2702]

Ich habe auch Multihost allerdings alles auf Linux und kein Redis.

[AlCalzone]

@wendy2702 sagte in Diskussion zum neuen Installation-Fixer:

Ich habe auch Multihost allerdings alles auf Linux und kein Redis.

Und tritt das Problem auf allen Hosts auf oder nur dem/den Slave(s)?

[wendy2702]

Habe den Fixer nur auf den Slaves ausgeführt und da tritt es auf.

[fischmir]

Ok, ich bin mal garnicht firm mit Linux, habe aber alles gegeben und komme nun nicht weiter. Was habe ich getan?

Per Purry auf iobroker drauf, eingeloggt und den Befehl ausgeführt, dann kamen mehrere Meldungen wie:

ioBroker or some processes are still running:
 io.rpi2.0
 io.socketio.0
 io.history.0
 io.javascript.0
 io.discovery.0
Please stop them first and try again!

--> Vorher standen dort mehr Instanzen, welche ich dann per Web beendet habe. Dummerweise habe ich auch dei io.admin.0-Instanz gestoppt, so dass ich per Browser die restlichen Adapter nicht mehr beenden kann.

Fragen:

1. Wie beende ich die restlichen Prozesse?
2. Ich würde dann das Script ausführen
3. Wie starte ich danach den io.admin.0-Instanz wieder?

Danke und Grüße,
Christian

[AlCalzone]

Das einfachste wäre gewesen, ioBroker komplett zu stoppen mit iobroker stop. Den Admin bekommst du wieder aktiviert mit iobroker start admin, danach sollte iobroker stop reichen (oder ggf. sudo iobroker stop, wenn das nicht hilft).

Wenn das alles gar nicht hilft, kannst du per

pkill io.rpi2.0

und so weiter die Adapterprozesse stoppen.

[fischmir]

Hi! Danke für deine Antwort. Leider hilft das alles nicht. Hier mal mein Auszug:

pi@ioBroker-RasPi:~ $ curl -sL https://iobroker.net/fix.sh | bash -
ioBroker or some processes are still running:
 io.socketio.0
 io.history.0
 io.javascript.0
 io.discovery.0
 io.admin.1
Please stop them first and try again!
pi@ioBroker-RasPi:~ $ sudo iobroker stop
iobroker controller daemon is not running
pi@ioBroker-RasPi:~ $ pkill io.rpi2.0
pkill: killing pid 5644 failed: Die Operation ist nicht erlaubt
pi@ioBroker-RasPi:~ $ pkill io.rpi3.0
pi@ioBroker-RasPi:~ $ sudo pkill io.rpi3.0
pi@ioBroker-RasPi:~ $ curl -sL https://iobroker.net/fix.sh | bash -
ioBroker or some processes are still running:
 io.socketio.0
 io.history.0
 io.javascript.0
 io.discovery.0
 io.admin.1
 io.rpi2.0
Please stop them first and try again!
pi@ioBroker-RasPi:~ $ sudo pkill io.rpi2.0
pi@ioBroker-RasPi:~ $ curl -sL https://iobroker.net/fix.sh | bash -
ioBroker or some processes are still running:
 io.socketio.0
 io.history.0
 io.javascript.0
 io.discovery.0
 io.admin.1
Please stop them first and try again!

Scheint also irgendwie nicht zu klappen....was kann ich nun noch versuchen?

Edit: Habe jetzt die instanzen per Browser beeendet, jetzt sieht es so aus:

pi@ioBroker-RasPi:~ $ curl -sL https://iobroker.net/fix.sh | bash -
ioBroker or some processes are still running:
 io.rpi2.0
Please stop them first and try again!
pi@ioBroker-RasPi:~ $ pkill io.rpi2.0
pkill: killing pid 5749 failed: Die Operation ist nicht erlaubt
pi@ioBroker-RasPi:~ $ sudo pkill io.rpi2.0
pi@ioBroker-RasPi:~ $ curl -sL https://iobroker.net/fix.sh | bash -
ioBroker or some processes are still running:
Please stop them first and try again!
pi@ioBroker-RasPi:~ $ sudo iobroker stop
iobroker controller daemon is not running
pi@ioBroker-RasPi:~ $ curl -sL https://iobroker.net/fix.sh | bash -
ioBroker or some processes are still running:
Please stop them first and try again!

Also obwohl keine Prozesse mehr laufen, wird nicht gestartet.

Nachschlag: Das sieht schon nicht gut aus:

pi@ioBroker-RasPi:~ $ sudo iobroker stop
Stopping iobroker controller daemon...
iobroker controller daemon stopped.
Exit code for "killall.sh": 123
pi@ioBroker-RasPi:~ $

Oder?

Habs Problem gefunden: Der rpc und rega-Adapter waren noch am laufen. Hätte mir gewünscht, dass das auch angezeigt wird. Nachdem ich beide Prozesse gekillt hatte, starteteten diese beiden neu?! Musst beide killen und schnell das INstaller-Fix-Skript starten; so hat es funktioniert.

[AlCalzone]

pi@ioBroker-RasPi:~ $ sudo pkill io.rpi2.0
pi@ioBroker-RasPi:~ $ curl -sL https://iobroker.net/fix.sh | bash -
ioBroker or some processes are still running:
 io.socketio.0
 io.history.0
 io.javascript.0
 io.discovery.0
 io.admin.1

Ja, ich meinte ja auch dass du alle Prozesse so beenden sollst, und nicht nur rpi2

@fischmir sagte in Diskussion zum neuen Installation-Fixer:

Also obwohl keine Prozesse mehr laufen, wird nicht gestartet.

Das ist tatsächlich ein Bug. Wir hatten vor einer Weile was am Prozess-Filter geändert und eine Zeile vergessen.

Aber gut dass es jetzt doch läuft.

[fischmir]

Anschließend habe ich alle Adapter ge-updated und nun startet iobroker nicht mehr

pi@ioBroker-RasPi:/opt/iobroker $ iobroker version
1.4.0
pi@ioBroker-RasPi:/opt/iobroker $ iobroker upgrade
 Cannot parse /opt/iobroker/node_modules/iobroker.js-controller/lib/objects/../../../../iobroker-data/objects.json: SyntaxError: Unexpected end of JSON input
 Cannot parse /opt/iobroker/node_modules/iobroker.js-controller/lib/objects/../../../../iobroker-data/objects.json.bak: SyntaxError: Unexpected end of JSON input
No repositories defined.
25

Das ist doof. Sonst lief alles immer problemlos. Was kann ich nun tun?

[apollon77]

Im iobroker Verzeichnis lieferbarer get noch ne .bak. Passt die? Sondt gibts da noch ein Backup-objects Verzeichnis mit noch mehr früheren Versionen. Ggf mit gunzip entpacken.

[duffbeer2000]

@AlCalzone said in Diskussion zum neuen Installation-Fixer:

Wenn im Container, läuft ioBroker danach tatsächlich als User "iobroker"?
Aber auch das macht keinen wirklichen Sinn, da bereits durch den Container der "Schutz" des Hosts geschaffen wird, den wir durch den User mit beschränkten Rechten erreichen wollen.

Hi AlCalzone, ich bastel gerade an nem neuen Docker Container. In den läuft ioBroker mit dem User "iobroker". Buanet bastelt da meines wissens auch dran. Zur Reparatur älterer Installationen die mit dem User root liefen oder wenn man Backups einspielt ist der Fixer echt gold wert. Hab mich jetzt mal durch den Thread gelesen und dachte das ist vielleicht interessant. Auch im Container sollte man wenn möglich auf den root User verzichten:

Artikel zum ausführen von Prozessen im Container als root:
[https://medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b](link url)
[https://medium.com/lucjuggery/running-a-container-with-a-non-root-user-e35830d1f42a](link url)

Wo liegen denn aktuell die Probleme beim Fixer im Container? Bis jetzt habe ich noch nichts drastisches gelesen. Ich teste morgen mal wie es sich verhält wenn man den iobroker Ordner per bind mount, also volume oder rein im Container hat.

[AlCalzone]

@duffbeer2000 Inzwischen sind die gröbsten Probleme mit Docker behoben, auch dank der Hilfe von Buanet. Das Problem war, dass der Fixer bestimmte Permissions für node setzt, die für manche Adapter nötig sind, aber in einem Container standardmäßig nicht verfügbar sind. Das hat im Endeffekt dafür gesorgt, dass man node im Container nicht mehr ausführen konnte.

Daher ist Fixer + Docker zur Zeit noch auf eigene Gefahr - auch wenn es vermutlich keine groben Schnitzer mehr gibt.

[bahnuhr]

@AlCalzone

gab es schon eine Lösung für mich und wendy?

fixer läuft ja durch.

problem war ja:
iobroker stop
iobroker status

[AlCalzone]

@bahnuhr nein leider nicht, da ich mangels multi host nicht nachvollziehen kann was genau schief geht. Welche Ausgabe bringt systemctl status iobroker nach iobroker start/stop jeweils?

[bahnuhr]

Ja, das mit dem systemctl klappt.
Aber das "einfachere" halt nicht.