Diskussion zum neuen Installation-Fixer
-
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!
-
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?
-
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 ?
-
@liv-in-sky was genau brauchst du denn?
-
hi
ich habe ein sript, welches mir alle processe anzeigt in einer tabelle - für vis
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  </td><td>"$2"</td></tr>"}'- alle linux processe
smem -nkrt --sort=pss | awk '{print "<tr><td class=\"getprocessswap\">"$(NF-3)"    </td>", "<td class=\"getprocessmem\">"$(NF-1)" </td>", "<td class=\"getprocessmem\">"$(NF-2)"   </td>", "<td>"$1"   </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>' -
@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
-
@liv-in-sky Ich habe hier jemand anderem beschrieben, wie er
scpfür seine Zwecke erlauben kann:
https://forum.iobroker.net/topic/9405/offen-root-rechte-für-exec/32Das kannst du sicher adaptieren, um die Befehle hinzuzufügen, die für dich relevant sind.
Am besten postest du hier noch die Liste der fehlenden Befehle, vielleicht kann man den ein oder anderen auch standardmäßig erlauben. -
hi @AlCalzone
mittlerweile habe ich wieder das system ohne fixer script am laufen - ich habe aber mal das ganze unter einem anderen user getestet - das hat funktioniert
vielen dank für diese info
mein system hat aber eh ein seltsames verhalten (letztes mal wolte ich den admin adapter updaten (über den admin) - danach ging der admin nicht mehr - dann nochmals über die console - ging dann wieder aber dafür funktionierte der sonoff und tr-064 adapter nicht mehr - auch der linux-dgram mußte in eine bestimmtes verzeichnis (ich glaube es war: /node_modules/winston) installiert werden, da sonst npm rebuild abbrach, ...)
ich bin daher eh am überlegen ob ich das ganze mal neu installiere - Stabilostick beschreibt dies als weg -c bei der node installation (Reset aller Module in node_modules)( https://forum.iobroker.net/topic/22867/how-to-node-js-für-iobroker-richtig-updaten/2?page=1 )
sollte ich dies machen, werde ich auch nochmal über das fixer script nachdenken - bei gelegenheit werde ich via proxmox die vm mit dem fixer nochmal laden und deinen vorschlag dort nochmal testen - wird sicher auch dort funktioniereneine liste mit befehlen, kann ich dir leider nicht geben, da ich nicht weiß, was ich sonst noch so abfragen werde. der smem befehl muss eh installiert werden und deshalb macht es vielleicht keinen sinn, den standardmäßig zu zulassen.
bei diesem befehl musste ich etwas tricksen , mit sudo bekomm ich das nicht hin
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  </td><td>"$2"</td></tr>"}'hab die for schleife in ein bashscript gepackt und rufe das mit sudo auf
sudo swapfind | sort -n -r | awk '$1 >= 0 {print "<tr><td class=\"getprocessswap1\" >"$1"kB  </td><td>"$2"</td></tr>"}' -
@liv-in-sky sagte in Diskussion zum neuen Installation-Fixer:
hab die for schleife in ein bashscript gepackt und rufe das mit sudo auf
Das wäre auch der einfachste Weg, mehrere Befehle auszuführen. Ein Bash-Skript anlegen und dessen Aufruf in der sudoers-Datei erlauben.
