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

[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.

[duffbeer2000]

@AlCalzone Hi, ich kenn mich leider mit GitHub Push Pull noch nicht so aus deshalb schreib ich es hier. Diesen Abschnitt im Installation-Fixer und Installer könnte man noch etwas erweitern dann erkennt er automatisch ob die capability CAP_NET_ADMIN gesetzt ist (getestet mit Debian):

Aktuell:

if running_in_docker; then
	setcap 'cap_net_bind_service,cap_net_raw+eip' $(eval readlink -f `which node`)
	echo "${yellow}Docker detected!"
	echo "If you have any adapters that need the CAP_NET_ADMIN capability,"
	echo "you need to start the docker container with the option --cap-add=NET_ADMIN"
	echo "and manually add that capability to node${normal}"
else
	$cmdline 'cap_net_admin,cap_net_bind_service,cap_net_raw+eip' $(eval readlink -f `which node`)
fi

Erweitert:

if running_in_docker; then
	capabilities=$(grep ^CapBnd /proc/$$/status)
	if [[ $(capsh --decode=${capabilities:(-16)}) == *"cap_net_admin"* ]]; then
		$cmdline 'cap_net_admin,cap_net_bind_service,cap_net_raw+eip' $(eval readlink -f `which node`)
	else
		setcap 'cap_net_bind_service,cap_net_raw+eip' $(eval readlink -f `which node`)
		echo "${yellow}Docker detected!"
		echo "If you have any adapters that need the CAP_NET_ADMIN capability,"
		echo "you need to start the docker container with the option --cap-add=NET_ADMIN"
		echo "and manually add that capability to node${normal}"
	fi
else
	$cmdline 'cap_net_admin,cap_net_bind_service,cap_net_raw+eip' $(eval readlink -f `which node`)
fi

[AlCalzone]

Cool, danke. Ich nehm es auf.

[darkbrain85]

Ich hatte immer ein Problem... IOBroker fing immer nach einigen Tagen an rum zu spinnen. Dies führte zum wahllosen automatischen restart von Adaptern.

Ich habe Wochenlang keine Lösung gefunden.

Einmal der fixer drüber laufen lassen und... tadaaaa.... seit 3 Woche rennt er durch :-D

Danke an alle beteiligten!

[BlurayXL]

HILFE!

hab den Fix durchgeführt, da mein BackitUp nicht mehr ging. Jetzt geht die Admin Oberfläche unter IP:8081 nicht mehr, wird nicht gefunden. Unter IP:8082 ist nur noch VIS und Editor aufgeführt, Admin fehlt. Was kann ich tun?

EDIT: Habe den Prozess Admin selbst gestartet mit
iobroker start admin
Man kommt jedoch nur noch über IP:8082 auf die Admin Oberfläche.

Wie kann ich diese beiden Sachen beheben?

[liv-in-sky]

kann es sein, dass mit dem fixer bestimmte exec() befehle nicht mehr richtig funktionieren, da sie nicht mehr unter root laufen ?

was kann ich dagegen tun ?

[apollon77]

@liv-in-sky was genau brauchst du denn?