Diskussion zum neuen Installation-Fixer

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:

Wie beende ich die restlichen Prozesse?
Ich würde dann das Script ausführen
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

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?

liv-in-sky

@apollon77

hi

ich habe ein sript, welches mir alle processe anzeigt in einer tabelle - für vis

Image 13.png

letztlich führt ein script einen exec() befehl mit smem aus und formatiert eine html tabelle - früher wurden mir alle processe angezeigt - ich konnte nach iobroker filtern usw. - jetzt komnmt nur das, was du im bild siehst

das sind die befehle, die jetzt nicht mehr anzeigen können, für was sie eigendlich gedacht waren:

processe, die swappen

for proc in /proc/*; do cat $proc/smaps 2>/dev/null | awk '/Swap/{swap+=$2}END{print swap"\t'`readlink $proc/exe`'"}'; done | sort -n -r | awk  '$1 > 0 {print "<tr><td  class=\"getprocessswap1\" >"$1"kB&emsp;&emsp;</td><td>"$2"</td></tr>"}'

alle linux processe

smem -nkrt --sort=pss | awk '{print  "<tr><td class=\"getprocessswap\">"$(NF-3)"&ensp;&ensp;&ensp; </td>", "<td class=\"getprocessmem\">"$(NF-1)"&ensp;</td>", "<td class=\"getprocessmem\">"$(NF-2)"&ensp;&ensp;&ensp;</td>", "<td>"$1"&ensp;&ensp; </td>", "<td>"$2"</td>","<td>" $3"</td></tr>"}'  | sed '1i <table>' | sed  '$a</table><p>PSS: Speicher mit anderen Shared --- USS: Speicher nur Process</p>'

liv-in-sky

@apollon77
hier noch die übersicht mit und ohne fixer:

mit fixer-script

das problem ist so: der iobroker user sendet den exec() mit smem - dieser bringt dann folgendes zurück: nur die prozesse, die er angeschoben hat - aber trotz fixer ist der iobroker als root gestartet (da mit root installiert) - er zeigt also nicht mal die iobroker-dienste an ! sichtbar auf bild - der user ist "1001"

ohne fixer : smem wird über root ausgeführt - dieser zeigt alle dienste an! user ist "0"
hier das bild ohne fixer

Image 1.png

NEWS

Diskussion zum neuen Installation-Fixer

Support us

703
Online

30.7k
Users

77.3k
Topics

1.2m
Posts

NEWS

Diskussion zum neuen Installation-Fixer

Support us

703Online

30.7kUsers

77.3kTopics

1.2mPosts

703
Online

30.7k
Users

77.3k
Topics

1.2m
Posts