UNSOLVED ständige Neustarts diverser Adapter
-
Hallo zusammen, ich habe ständig das Log voll mit Fehlermeldungen, dass ein Adapter nicht gestartet werden kann, da er schon läuft.
z.B.
host.ioBroker-RasPi 2019-02-22 11:17:15.592 error instance system.adapter.sql.0 terminated with code 7 (Adapter already running)
host.ioBroker-RasPi 2019-02-22 11:28:00.694 error Caught by controller[0]: Cannot find module 'pg-native'
Im moment ist es der SQL Adapter, der scheinbar immer wieder neu startet. Der SQL Server läuft extern auf auf einer Synologystation, die mir keine Fehlermeldung ausgibt. Ich gehe also davon aus, dass seitens der Synology alles glatt läuft.Dies geschieht mit allen möglichen Adaptern.
Das System wurde von mir vor 2 Wochen komplett neu aufgesetzt, unter anderem wegen eben dieser Fehler. Leider ist mir Anfangs nicht aufgefallen dass als Repository Latest eingestellt war. Allerdings betrifft das derzeit nur den Admin adapter der auf 3.6.0 statt 3.5.10 steht sowie den Broadlinkadapter der auf 3.9.1 statt 3.8.0 sowie den hmrpc mit 1.9.7 statt 1.9.6. Das Problem ist wohl dass aus welchen Gründen auch immer, die Adapter immer neu gestartet werden. Zumindest wird der Neustart angestoßen.
Jemand eine Idee? npm ist 6.4.1 und node ist 8.15.0
js controller ist 1.5.7 (?) kann das der Fehler sein? Und wenn ja wie komme ich auf die Version 1.4.2 zurück? -
@michaelxhoffmann sagte in ständige Neustarts diverser Adapter:
terminated with code 7 (Adapter already running)
Das bedeutet dass davon zwei Prozesse laufen.
Warum auch immer.Da bei hilft
Raspi rebooten
Oder über die Konsole sauber die Prozesse killen -
@Homoran Ja, das mit dem Prozesse killen ist so eine Sache. Ist mir auch schon aufgefallen. manchmal kommt bei einem stop diese Fehlermeldung: No "killall.sh" script found. Just stop. Muss ich das händisch anlegen? gehört das ins /opt/iobrokerverzeicnis hinein?
-
@michaelxhoffmann
Was willst du tun?Du musst auf Linux Ebene den Linux Prozess killen
-
@Homoran naja es scheint so dass das Script killall.sh nicht vorhanden ist. Gehe ich falsch in der Annahme, dass normalerweise diese Datei vorhanden ist wenn ich ein Image installiere? Andererseits ist dieses Script weder im Raspi noch im Rock image vorhanden. Und was ich tun möchte? Beim stopen des Brokers den richtigen killallbefehl mitsenden
-
Die interessante Frage ist was da slog so alles ausgibt BEVOR das das erste mal passiert. Also am besten mal rebooten bzw iobroker stoppen und alle Prozesse killen. Dann schauen was genau im Log steht wenn es wieder passiert
-
@apollon77 Naja wenn ich im Terminal den Befehl iobroker stop eingebe erhalte ich als Antwort:
No "killall.sh" script found. Just stop.
Deshalb meine Frage: Was steht normalerweise in diesem Script drin und wie kann ich das händisch anlegen, oder was muss ich dafür tun damit es wieder da ist?
-
mach mal nach Stopp ein
ps auxww|grep "io."Dann siehst Du Prozesse mit "io.adaptername.nummer" ... und die im Zweifel manuell mit "kill -9 <prozessID>" killen
-
@apollon77 sagte in ständige Neustarts diverser Adapter:
ps auxww|grep "io."
Ja, das habe ich schon verstanden, aber das beseitigt ja nicht das eigentliche Problem: Das fehlen der killall.sh Datei und deren Inhalt.
-
OK Nun weiß ich was es mit der killall.sh auf sich hat. Ich weiß nicht weshalb ich die JS-controller Version 1.5.7 auf den Geräten drauf hatte, ich habe jetzt ein Downgrade vorgenommen beim Master auf js-controller 1.4.2 nun ist dass killall.sh Script als datei wieder vorhanden im Verzeichnis /opt/iobroker/
Jetzt funktioniert auch der sudo iobroker stop Befehl wieder ohne Fehlermeldung -
@michaelxhoffmann Und schon machen sich neue Probleme bemerkbar. Nun startet der slavehostadapter ständig neu und ich hbe viele tolle Fehlermeldungen vom slave im Log
Ein Fehler beseitigt, einen neuen Kreiert. Das kann doch echt nicht sein.
Nun habe ich die Fehler auf dem Slave, vorher hatte ich andere auf dem master. Was habe ich gemacht? Alle adapter zurückgesetzt auf Default und die js--controller zurückgesetzt auf 1.4.2 -
Du hast ein root vs User mixup geschafft. Das pids.txt gehört denke ich root aber du startest als User. Ergo geht nicht.
Vllt mal https://forum.iobroker.net/topic/20211/iobroker-installation-fixer-beta-verfügbar versuchen?
-
@apollon77 Ja, der master läuft auf root und der slave auf pi. Das war wohl von den jeweiligen Images so vorgegeben.
Auf welchem Gerät muss ich das jetzt ausführen, auf dem master oder auf dem slave? Oder auf beiden? Was mich etas irritiert ist, dass DIESER Fehler erst jetzt auftaucht. -
siehe FAQ in dem Artikel?
-
@apollon77 Ja, habe ich gesehen. Auch dannach durchgeführt auf dem Slave. Was mir nicht klar ist ob ich das dann auch auf dem Master ausführen muss.
-
Müssen nicht ... schaden tut es ggf auch nicht einheitliche systeme zu haben
-
@apollon77 OK
Habe ich auf beiden Systemen ausgeführt. Bisher sind keine neuen Fehlermeldungen aufgetaucht. Und Instanzen die laufen sollen tun dies auch. Nun denn warten wir mal ab! Danke für die Hilfe jedenfalls!
