NEWS
Diskussion zum neuen Installation-Fixer
-
Probierst Du bitte mal von hier:
https://unix.stackexchange.com/questions/10735/allowing-a-user-to-let-listen-to-a-port-below-1024am besten wieder mit dem "which node" wie bei dem anderen. Dann fehlt das noch im Installer und Fixer, Wenns tut am besten wieder GitHub issue?
-
An der NPM Version liegt es nicht, schreibt apollon77 auch auf Github. NPM führt wenn überhaupt zu Problemen bie der Installation, was dann wiederum andere Probleme verursachen könnte. Aber auch zur 6.8 schreibt er dass eigentlich keine Problem bekannt sind. Was im Widerspruch zu einigen Berichten hier zur der 6.8 steht. Er wird schon wissen was er schreibt, in der Regel werden oft bestehende Probleme mit einer neuen Version in Verbindung gebracht, ob das zutrifft ist was anderes
-
@apollon77 setcap 'cap_net_bind_service=+ep' /path/to/program
welchen Pfad genau, dem vom Webserver? -
@ilovegym sagte in Diskussion zum neuen Installation-Fixer:
$(readlink -f $(which node))
Denke wieder $(readlink -f $(which node))
-
@apollon77 Danke, genau das war es!
sudo setcap 'cap_net_bind_service=+ep' $(readlink -f $(which node))schön, läuft wieder... aber warum verstellt der sowas..??
-
@Bluefox @apollon77
Ich werf mich weg.. Nach dem Fixer, einem Downgrade auf NPM6.5.0 und dem sudo setcap 'cap_net_bind_service=+ep' $(readlink -f $(which node)) , wurde wohl mein Javascriptadapter von 4.0.12 auf 4.1.3 geupdatet, hatte damit ja die ganze Zeit Probleme mit ein paar Blocklys, die "cannot extract blocky" erzeugten und absolut nicht zu bearbeiten waren.Jetzt gehts! Also war doch ein Rechte-Problem, denk ich mal.. in der Browser-Console stand ja auch immer was mit "not permitted"...
-
Das Blockly Problem ist unabhängig davon und hatte ich auch, ist aber mit der aktuellen Version 4.1.3 des JS Adapter eh gefixt.
-
@Jan1 nee, war eben nicht so, habs auf 3 Systemen mit dem Fehler..
-
@ilovegym
OK, das ist dann aber noch mal ne andere Hausnummer, da ich nämlich auch das Issues dafür auf Github geöffnet hatte und bei mir das mit der Version 4.1.3 endgültig behoben war.
Gut wenn das bei Dir jetzt aber auch läuft. -
@dslraser sagte in Diskussion zum neuen Installation-Fixer:
@apollon77ich habe das bei meiner Installation mal laufen lassen (ioBroker im Docker Container auf der Synology) Bisher lief nach einem Backup iobroker nicht automatisch wieder an, das scheint damit auch behoben zu sein und zu funktionieren. Jedenfalls hat es eben funktioniert.
habe es auch gerade im Docker auf der Synology gemacht.
Kann ioBroker nicht mehr starten.
EDIT: Kommando retour!
Hab den Container aus- und wieder eingeschaltet. Dann lief wieder alles.Einige Adapter mussten noch händisch gestartet werden.
-
Wie sieht das mit Multihost aus?
Den Fix auf beiden Systemen ausführen? -
Ja, jede Installation ist ja unabhängig
-
ioBroker or some processes are still running: io.broadlink.0 io.rxtx. io.mqtt.0 io.zigbee.0 io.discovery.0 io.iot.0 io.backitup.0 io.js2fs.0 io.javascript.1 io.admin.0 Please stop them first and try again!
Muss ich iobroker stoppen
Was ist denn io.rxtxpi@raspberrypi:~ $ curl -sL https://raw.githubusercontent.com/ioBroker/ioBroker/stable-installer/fix_installation.sh | bash -
ioBroker or some processes are still running:
io.rxtx.
Please stop them first and try again! -
Naja die Meldung sagt was du tun sollst. Also ja bitte stoppen.
Interessant ist der io.rxtx. ... das scheint ein anderer Prozess zu sein von deinem System. Oder ist das ein Adapter den du hast?
-
Ich kenne den nicht
pi@raspberrypi:/opt/iobroker $ iobroker stop rxtx Cannot find any instances of "rxtx"
-
Dann ist es vllt was ganz anderes was mit iobroker gar Nichts zu tun hat. Mach mal
ps auxwww|grep rxtx
-
root 2809 3.3 5.0 272952 48160 ? Sl 18:22 0:46 java -Xmx128m -Dos.arch=arm -Dlog4j.configuration=file:///etc/config/log4j.xml -Dfile.encoding=ISO-8859-1 -Dgnu.io.rxtx.SerialPorts=/dev/mmd_hmip -jar /opt/HMServer/HMIPServer.jar /etc/crRFD.conf /etc/HMServer.conf root 19498 0.0 0.0 4368 548 pts/1 S+ 18:45 0:00 grep rxtx
-
Hehe. Da läuft was in Java und das erkennt fälschlicherweise das Namensschema. Bitte mal als GitHub issue in ioBroker/ioBroker im GitHub.
-
Installationsfixer lief bei mir fehlerfrei durch und alle Instanzen starteten problemlos auf meinem System (alles grün und der Log ist "leer")
(Odroid XU4 mit Armbian 5.73, node 8.15.0, npm 6.4.1,
ioBroker mit ioBroker admin 3.6.0, js-controller Version 1.4.2 und
Adapter (von ioT, hmip, backitup, dasWetter, sonoff, HS100, Tankerkönig, mihome-vacuum bis Telegram und noch mehr) mit stable Release) -
Участник @Yetiberg написал в Diskussion zum neuen Installation-Fixer:
HMServer/HMIPServer.jar
Das sieht nach OCCU aus: https://github.com/eq-3/occu/blob/master/HMserver/etc/init.d/S62HMServer