Diskussion zum neuen Installation-Fixer
-
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
-
Ahhh, neue Informationen... Das Problem tritt also nur auf dem Slave im Multihost auf? @wendy2702 Bist du auch auf Multihost unterwegs?
-
@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. -
Ich habe auch Multihost allerdings alles auf Linux und kein Redis.
-
@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)?
-
Habe den Fixer nur auf den Slaves ausgeführt und da tritt es auf.
-
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 -
Das einfachste wäre gewesen, ioBroker komplett zu stoppen mit
iobroker stop. Den Admin bekommst du wieder aktiviert mitiobroker start admin, danach sollteiobroker stopreichen (oder ggf.sudo iobroker stop, wenn das nicht hilft).Wenn das alles gar nicht hilft, kannst du per
pkill io.rpi2.0und so weiter die Adapterprozesse stoppen.
-
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.
-
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.1Ja, 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.
-
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. 25Das ist doof. Sonst lief alles immer problemlos. Was kann ich nun tun?
-
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.
-
@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.
-
@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
nodesetzt, 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 mannodeim 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.
-
gab es schon eine Lösung für mich und wendy?
fixer läuft ja durch.
problem war ja:
iobroker stop
iobroker status -
@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?
-
Ja, das mit dem systemctl klappt.
Aber das "einfachere" halt nicht. -
@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`) fiErweitert:
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 -
Cool, danke. Ich nehm es auf.
-
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!
