NEWS
Instanzen laufen instabil u.a.admin,yakha-gelöst
-
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
Lohnt es sich iobroker auf einem Pi zu installieren ?
Wo läuft es denn jetzt?
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
Laufen die Instanzen da stabil ?
Die sollen überall stabil laufen!
Insgesamt kann ich mit den wenigen Informationen nichts anfangen.
Im log müssen Informationen stehen, wenn etwas ursächlich Probleme hat.Ich hätte noch die ein oder andere Idee, doch erstmal bräuchte ich die Informationen wo und wie es jetzt läuft
@Homoran said in Instanzen laufen nicht stabil (u.a. admin, yakha):
Insgesamt kann ich mit den wenigen Informationen nichts anfangen.
Ich sagte ja, ich hoffe, ich drücke mich verständlich aus;-)
Also aktuell habe ich einige Installationen;-) Die laufen als virtuelle Maschinen auf einem Xenserver. Der yakha Adapter konfiguriert ist nur auf einer virtuellen Maschine, wo debian 10 installiert ist und aktuell eben die Versionsnummern, die ich oben installiert hab - das Verhalten war aber auch schon direkt nach der Installation (also admin 3.6.2, die npm Version weiß ich gerade nicht mehr aus dem Kopf.
Um eben zu testen, ob es an bestimmten Versionen oder auch Adaptern liegt, habe ich weitere iobroker-Installationen gestartet. 2x noch auf debian 10 und dann noch mal auf ubuntu Server 18. Das Verhalten, dass die Instanzen nach einigen Minuten nicht mehr "laufen" habe ich auf all diesen Installationen gehabt.
Also bei admin ist es eben so, dass die Seite iobroker nicht richtig geladen wird. der obere Teil der Seite startet und man sieht im oberen Teil den Ladebalken - aber mehr passiert nciht.
Bei den anderen Adaptern (yahka, shelly, fritzbox) gehen die mit der Zeit auf rot. Wenn ich halt mit
"iobroker restart admin/yahka/usw" bekäm ich alles wieder gestartet.
Aktuelles Workaround ist halt auch über den Cronjob die Adapter regelmäßig neu zu starten. Aber das ist ja ansich nicht im Sinne des Erfinders;-)Ich teste gleich, ab wann die einzelnen Adapter nicht mehr erreichbar sind und dann füge ich syslog und die iobroker.log hinzu. Ich hab mit tail die logs halt auch mal laufen lassen, aber ich habe leider nichts auffälliges gesehen. yahka hatte ich auch auf silly gestellt. Soll ich das bei den anderen Adaptern auch machen oder lieber nur debug ?
Wegen des Pis war nur meine Frage, ob es sich lohnen würde, da noch mal eine Installation zu starten. Ich vermute eher, dass ich irgendeine Version habe, die unverträglich ist. Frage nur welche.
Vielen Dank und viele Grüße
-
@Homoran said in Instanzen laufen nicht stabil (u.a. admin, yakha):
Insgesamt kann ich mit den wenigen Informationen nichts anfangen.
Ich sagte ja, ich hoffe, ich drücke mich verständlich aus;-)
Also aktuell habe ich einige Installationen;-) Die laufen als virtuelle Maschinen auf einem Xenserver. Der yakha Adapter konfiguriert ist nur auf einer virtuellen Maschine, wo debian 10 installiert ist und aktuell eben die Versionsnummern, die ich oben installiert hab - das Verhalten war aber auch schon direkt nach der Installation (also admin 3.6.2, die npm Version weiß ich gerade nicht mehr aus dem Kopf.
Um eben zu testen, ob es an bestimmten Versionen oder auch Adaptern liegt, habe ich weitere iobroker-Installationen gestartet. 2x noch auf debian 10 und dann noch mal auf ubuntu Server 18. Das Verhalten, dass die Instanzen nach einigen Minuten nicht mehr "laufen" habe ich auf all diesen Installationen gehabt.
Also bei admin ist es eben so, dass die Seite iobroker nicht richtig geladen wird. der obere Teil der Seite startet und man sieht im oberen Teil den Ladebalken - aber mehr passiert nciht.
Bei den anderen Adaptern (yahka, shelly, fritzbox) gehen die mit der Zeit auf rot. Wenn ich halt mit
"iobroker restart admin/yahka/usw" bekäm ich alles wieder gestartet.
Aktuelles Workaround ist halt auch über den Cronjob die Adapter regelmäßig neu zu starten. Aber das ist ja ansich nicht im Sinne des Erfinders;-)Ich teste gleich, ab wann die einzelnen Adapter nicht mehr erreichbar sind und dann füge ich syslog und die iobroker.log hinzu. Ich hab mit tail die logs halt auch mal laufen lassen, aber ich habe leider nichts auffälliges gesehen. yahka hatte ich auch auf silly gestellt. Soll ich das bei den anderen Adaptern auch machen oder lieber nur debug ?
Wegen des Pis war nur meine Frage, ob es sich lohnen würde, da noch mal eine Installation zu starten. Ich vermute eher, dass ich irgendeine Version habe, die unverträglich ist. Frage nur welche.
Vielen Dank und viele Grüße
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
dass ich irgendeine Version habe, die unverträglich ist.
Da wäre es natürlich hilfreich die Versionen zu kennen.
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
Die laufen als virtuelle Maschinen auf einem Xenserver.
Bei VMs sollte es eigentlich keine Probleme geben, anders ist es bei Containern.
Aber bleiben wir nur bei dem Admin.
Der MUSS problemlos laufen.Wenn ALLE Installationen das Problem haben, scheint es ja ein systematischer Fehler zu sein.
Wie sieht es denn aus wenn du in einer VM nur nodejs, npm und ioBroker installierst, keine zusätzlichen Adapter außer dem admin.
Ursachen könnten gleiche IPs der VMs sein.
Fehlkonfiguration des Admins
zu wenig RAM
resp. zu viele Instanzen für das RAModer, oder oder.....
-
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
dass ich irgendeine Version habe, die unverträglich ist.
Da wäre es natürlich hilfreich die Versionen zu kennen.
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
Die laufen als virtuelle Maschinen auf einem Xenserver.
Bei VMs sollte es eigentlich keine Probleme geben, anders ist es bei Containern.
Aber bleiben wir nur bei dem Admin.
Der MUSS problemlos laufen.Wenn ALLE Installationen das Problem haben, scheint es ja ein systematischer Fehler zu sein.
Wie sieht es denn aus wenn du in einer VM nur nodejs, npm und ioBroker installierst, keine zusätzlichen Adapter außer dem admin.
Ursachen könnten gleiche IPs der VMs sein.
Fehlkonfiguration des Admins
zu wenig RAM
resp. zu viele Instanzen für das RAModer, oder oder.....
@Homoran said in Instanzen laufen nicht stabil (u.a. admin, yakha):
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
dass ich irgendeine Version habe, die unverträglich ist.
Da wäre es natürlich hilfreich die Versionen zu kennen.
ich sagte ja eingangs, dass aktuell admin 3.7.2 und Node.js v10.17.0 und NPM: 6.13.4 installiert ist. yahka 0.9.2 ist mittlerweile auch drauf.
Dass es an die Adapter liegen könnte, hatte ich auch schon vermutet, daher hatte ich auch schon eine "reine" Installation probiert - ohne zusätzliche Adapter. aber da verhielt sich der admin ebenso. Habe da erst mit der installierten Version das laufen gehabt (admin 3.6.2) und dann auch auf latest umgestellt so wurde es dann auch admin 3.7.2. Mein letzter Test heute war halt, dass ich auch npm und node geupdatet hab - aber gleiches Verhalten.
Die VMs gebe ich meist 1GB RAM - sollte für Linux reichen, dacht ich. Habe aber auf der, wo die yahka Adapter eingerichtet sind auch auf 2GB erhöht - aber auch kein anderes Verhalten.
IP Adresskonflikt glaube ich weniger, daher ich, wenn ich auf manuelle gehe, vorher überprüfe, ob die IP Adresse wirklilch frei ist.
Aktuell "teste" ich ja gerade, um die Logs hier zu posten, und ungefähre Zeiten zu nennen, wann was passiert. Interessant finde ich, dass der admin gerade immer erreichbar ist.
Mein Mann greift sonst mit seinem ipad auf den iobroker zu. Das hat er jetzt seit dem Testlauf nicht gemacht - nur ich über Windows Notebook mit Firefox. Ob da ein Zusammenhang sein könnte ?!
Mein Mann greift jetzt auch wieder mit seinem ipad auf die Seite zu. Sobald der admin jetzt sein problematisches Verhalten zeig, lad ich die Logs hoch.Falls noch mehr Informationen helfen können, such ich die gerne raus. Falls wie gesagt jemand sagen würde, er hat aktuell gerade installiert mit Versionen X auf debian/ubuntu oder ähnliches - dann würde ich das gerne versuchen zu rekonstruieren. Neue VM wäre relativ schnell installiert, PI hätte ich halt auch noch zum rumspielen da.
LG und vielen Dank bis dahin
-
@Homoran said in Instanzen laufen nicht stabil (u.a. admin, yakha):
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
dass ich irgendeine Version habe, die unverträglich ist.
Da wäre es natürlich hilfreich die Versionen zu kennen.
ich sagte ja eingangs, dass aktuell admin 3.7.2 und Node.js v10.17.0 und NPM: 6.13.4 installiert ist. yahka 0.9.2 ist mittlerweile auch drauf.
Dass es an die Adapter liegen könnte, hatte ich auch schon vermutet, daher hatte ich auch schon eine "reine" Installation probiert - ohne zusätzliche Adapter. aber da verhielt sich der admin ebenso. Habe da erst mit der installierten Version das laufen gehabt (admin 3.6.2) und dann auch auf latest umgestellt so wurde es dann auch admin 3.7.2. Mein letzter Test heute war halt, dass ich auch npm und node geupdatet hab - aber gleiches Verhalten.
Die VMs gebe ich meist 1GB RAM - sollte für Linux reichen, dacht ich. Habe aber auf der, wo die yahka Adapter eingerichtet sind auch auf 2GB erhöht - aber auch kein anderes Verhalten.
IP Adresskonflikt glaube ich weniger, daher ich, wenn ich auf manuelle gehe, vorher überprüfe, ob die IP Adresse wirklilch frei ist.
Aktuell "teste" ich ja gerade, um die Logs hier zu posten, und ungefähre Zeiten zu nennen, wann was passiert. Interessant finde ich, dass der admin gerade immer erreichbar ist.
Mein Mann greift sonst mit seinem ipad auf den iobroker zu. Das hat er jetzt seit dem Testlauf nicht gemacht - nur ich über Windows Notebook mit Firefox. Ob da ein Zusammenhang sein könnte ?!
Mein Mann greift jetzt auch wieder mit seinem ipad auf die Seite zu. Sobald der admin jetzt sein problematisches Verhalten zeig, lad ich die Logs hoch.Falls noch mehr Informationen helfen können, such ich die gerne raus. Falls wie gesagt jemand sagen würde, er hat aktuell gerade installiert mit Versionen X auf debian/ubuntu oder ähnliches - dann würde ich das gerne versuchen zu rekonstruieren. Neue VM wäre relativ schnell installiert, PI hätte ich halt auch noch zum rumspielen da.
LG und vielen Dank bis dahin
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
Die VMs gebe ich meist 1GB RAM
Die 1GB RAM, wie sie z.B. bei Raspberry Pi 2/3 zur Verfügung stehen reichen so gerade um mal mit ioBroker zu schnuppern.
Mit einem headless Linux und ca. 15 Adaptern ist aber Schluss. Daher werden mindestens 2GB, besser 4GB RAM empfohlen.Somit sollte ioBroker nur mit admin eigentlich störungsfrei laufen.
Die Versionen sind egal, bei mir läuft alles, latest und stable. Nodejs v6, v8 und v10.Da sollte es auch zu keinem Problem kommen.
Ich habe im Moment keine Ahnung woran es liegen könnte, kenne aber auch die VM-Konstrukte nicht.
Bitte mal über die Konsole eingeben:
iobroker list instancesUnd was immer hilft ist die Auslastung zu shen mit
topvon beiden bitte die Ausgabe posten
-
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
Die VMs gebe ich meist 1GB RAM
Die 1GB RAM, wie sie z.B. bei Raspberry Pi 2/3 zur Verfügung stehen reichen so gerade um mal mit ioBroker zu schnuppern.
Mit einem headless Linux und ca. 15 Adaptern ist aber Schluss. Daher werden mindestens 2GB, besser 4GB RAM empfohlen.Somit sollte ioBroker nur mit admin eigentlich störungsfrei laufen.
Die Versionen sind egal, bei mir läuft alles, latest und stable. Nodejs v6, v8 und v10.Da sollte es auch zu keinem Problem kommen.
Ich habe im Moment keine Ahnung woran es liegen könnte, kenne aber auch die VM-Konstrukte nicht.
Bitte mal über die Konsole eingeben:
iobroker list instancesUnd was immer hilft ist die Auslastung zu shen mit
topvon beiden bitte die Ausgabe posten
@Homoran
list instances habe ich schon öfter kontrolliert - auch, wenn die Instanzen nicht mehr reagieren - die "laufen" da dann immer noch
. Hier mal aktuelle Ausgabe:root@srvdeb3:~# iobroker list instances system.adapter.admin.0 : admin - enabled, port: 8081, bind: 0.0.0.0, run as: admin system.adapter.discovery.0 : discovery - enabled system.adapter.fritzbox.0 : fritzbox - disabled system.adapter.fritzdect.1 : fritzdect - enabled system.adapter.history.0 : history - enabled system.adapter.info.0 : info - enabled system.adapter.javascript.0 : javascript - disabled system.adapter.mobile.0 : mobile - enabled system.adapter.ping.0 : ping - disabled system.adapter.shelly.0 : shelly - enabled, port: 1882, bind: 0.0.0.0 system.adapter.shelly.1 : shelly - enabled, port: 1882, bind: 0.0.0.0 system.adapter.web.0 : web - disabled, port: 8082, bind: 0.0.0.0, run as: admin system.adapter.yahka.0 : yahka - enabled + instance is alive root@srvdeb3:~#mit top hab ich auch öfter beobachten, ob mir bei dem "crash" irgendwas auffallen könnte - aber leider auch ohne Erfolg.
top - 21:16:14 up 2:14, 1 user, load average: 0,00, 0,01, 0,00 Tasks: 99 total, 1 running, 98 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,2 us, 0,0 sy, 0,0 ni, 99,7 id, 0,1 wa, 0,0 hi, 0,0 si, 0,1 st MiB Mem : 1968,1 total, 1150,6 free, 532,5 used, 285,0 buff/cache MiB Swap: 1018,0 total, 1018,0 free, 0,0 used. 1286,8 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 412 redis 20 0 51672 9584 2972 S 0,3 0,5 0:11.30 redis-se+ 416 iobroker 20 0 923336 95140 27344 S 0,3 4,7 0:26.64 iobroker+ 1116 iobroker 20 0 912432 80768 26960 S 0,3 4,0 0:13.49 io.shell+ 1 root 20 0 21840 9740 7676 S 0,0 0,5 0:00.66 systemd 2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd 3 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_par_+ 6 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kworker/+ 7 root 20 0 0 0 0 I 0,0 0,0 0:00.01 kworker/+ 8 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 mm_percp+ 9 root 20 0 0 0 0 S 0,0 0,0 0:00.07 ksoftirq+ 10 root 20 0 0 0 0 I 0,0 0,0 0:03.01 rcu_sched 11 root 20 0 0 0 0 I 0,0 0,0 0:00.00 rcu_bh 12 root rt 0 0 0 0 S 0,0 0,0 0:00.01 migratio+ 13 root 20 0 0 0 0 I 0,0 0,0 0:00.00 kworker/+ 14 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/0 15 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/1Anbei auch die Logs. Habe die 3. Stelle unserer IPAdressen geixt - nur falls das wer anmerken möchte;-)
Zum Verlauf: um 19 Uhr habe ich einen Neustart gemacht. Gegen 19:05 war yahka und shelly.0 schon rot. Um 19:12 shelly.1 rot. Zwischen 19:20-19:30 fritzdect.1 rot und zwischen 20:05-20:17 Uhr admin und um 20:18 Neustart admin.
Da der Admin ja nicht so schnell "abgeraucht" ist - habe ich auch angefangen, yahka wieder neu zu laden.
Ich weiß auch gar nicht genau, "wie" ich den Fehler benennen soll, weil ich so nichts seh... "Abrauchen", "Crash" ist ja auch falsch, da die Instanz noch läuft.
Wir hatten yahka z.B. mal mit cron neu starten lassen alle paar Minuten und wenn admin dann nicht erreichbar war, war yahka tatsächlich noch erreichbar.Als ich eben die Logs angesehen habe, habe ich gesehen, dass die Netzwerkkarte nicht "rund" erkannt wird beim booten... Also für meinen Geschmach nicht ganz rund...
Meine VMs laufen ja auf Xenserver. die haben auch xentools - die betreffen meine ich auch die Netzwerkkarte. Ich installier die mal, vielleicht bringt das auch was.
Denn sonst ist der einzige gleiche Nenner, dass es VMs auf Xenserver sind.
iobroker.2019-12-14.fehler.log -
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
Die VMs gebe ich meist 1GB RAM
Die 1GB RAM, wie sie z.B. bei Raspberry Pi 2/3 zur Verfügung stehen reichen so gerade um mal mit ioBroker zu schnuppern.
Mit einem headless Linux und ca. 15 Adaptern ist aber Schluss. Daher werden mindestens 2GB, besser 4GB RAM empfohlen.Somit sollte ioBroker nur mit admin eigentlich störungsfrei laufen.
Die Versionen sind egal, bei mir läuft alles, latest und stable. Nodejs v6, v8 und v10.Da sollte es auch zu keinem Problem kommen.
Ich habe im Moment keine Ahnung woran es liegen könnte, kenne aber auch die VM-Konstrukte nicht.
Bitte mal über die Konsole eingeben:
iobroker list instancesUnd was immer hilft ist die Auslastung zu shen mit
topvon beiden bitte die Ausgabe posten
@Homoran said in Instanzen laufen nicht stabil (u.a. admin, yakha):
Die Versionen sind egal, bei mir läuft alles, latest und stable. Nodejs v6, v8 und v10.
dann werde ich Morgen sonst doch noch mal auf dem PI installieren. Die Installation sollte ansich dann ja laufen.
Ich finde den Beitrag hier gerade nicht... Aber ich dachte, ich hätte hier auch von einer Person gelesen, die am 5.12. postete, dass eine Neuinstallation auf einem Pi auch Probleme beim admin hatte. -
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
Die VMs gebe ich meist 1GB RAM
Die 1GB RAM, wie sie z.B. bei Raspberry Pi 2/3 zur Verfügung stehen reichen so gerade um mal mit ioBroker zu schnuppern.
Mit einem headless Linux und ca. 15 Adaptern ist aber Schluss. Daher werden mindestens 2GB, besser 4GB RAM empfohlen.Somit sollte ioBroker nur mit admin eigentlich störungsfrei laufen.
Die Versionen sind egal, bei mir läuft alles, latest und stable. Nodejs v6, v8 und v10.Da sollte es auch zu keinem Problem kommen.
Ich habe im Moment keine Ahnung woran es liegen könnte, kenne aber auch die VM-Konstrukte nicht.
Bitte mal über die Konsole eingeben:
iobroker list instancesUnd was immer hilft ist die Auslastung zu shen mit
topvon beiden bitte die Ausgabe posten
@Homoran said in Instanzen laufen nicht stabil (u.a. admin, yakha):
Somit sollte ioBroker nur mit admin eigentlich störungsfrei laufen.
Die Versionen sind egal, bei mir läuft alles, latest und stable. Nodejs v6, v8 und v10.Hast du verschlüsselte Verbindung aktiv ? Also dass der Zugriff über https erfolgt ? Bisher hatte ich das noch nicht aktiv. Dachte mir aber, dass ich das auch noch mal testen könnte.
-
@Homoran
list instances habe ich schon öfter kontrolliert - auch, wenn die Instanzen nicht mehr reagieren - die "laufen" da dann immer noch
. Hier mal aktuelle Ausgabe:root@srvdeb3:~# iobroker list instances system.adapter.admin.0 : admin - enabled, port: 8081, bind: 0.0.0.0, run as: admin system.adapter.discovery.0 : discovery - enabled system.adapter.fritzbox.0 : fritzbox - disabled system.adapter.fritzdect.1 : fritzdect - enabled system.adapter.history.0 : history - enabled system.adapter.info.0 : info - enabled system.adapter.javascript.0 : javascript - disabled system.adapter.mobile.0 : mobile - enabled system.adapter.ping.0 : ping - disabled system.adapter.shelly.0 : shelly - enabled, port: 1882, bind: 0.0.0.0 system.adapter.shelly.1 : shelly - enabled, port: 1882, bind: 0.0.0.0 system.adapter.web.0 : web - disabled, port: 8082, bind: 0.0.0.0, run as: admin system.adapter.yahka.0 : yahka - enabled + instance is alive root@srvdeb3:~#mit top hab ich auch öfter beobachten, ob mir bei dem "crash" irgendwas auffallen könnte - aber leider auch ohne Erfolg.
top - 21:16:14 up 2:14, 1 user, load average: 0,00, 0,01, 0,00 Tasks: 99 total, 1 running, 98 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,2 us, 0,0 sy, 0,0 ni, 99,7 id, 0,1 wa, 0,0 hi, 0,0 si, 0,1 st MiB Mem : 1968,1 total, 1150,6 free, 532,5 used, 285,0 buff/cache MiB Swap: 1018,0 total, 1018,0 free, 0,0 used. 1286,8 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 412 redis 20 0 51672 9584 2972 S 0,3 0,5 0:11.30 redis-se+ 416 iobroker 20 0 923336 95140 27344 S 0,3 4,7 0:26.64 iobroker+ 1116 iobroker 20 0 912432 80768 26960 S 0,3 4,0 0:13.49 io.shell+ 1 root 20 0 21840 9740 7676 S 0,0 0,5 0:00.66 systemd 2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd 3 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_par_+ 6 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kworker/+ 7 root 20 0 0 0 0 I 0,0 0,0 0:00.01 kworker/+ 8 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 mm_percp+ 9 root 20 0 0 0 0 S 0,0 0,0 0:00.07 ksoftirq+ 10 root 20 0 0 0 0 I 0,0 0,0 0:03.01 rcu_sched 11 root 20 0 0 0 0 I 0,0 0,0 0:00.00 rcu_bh 12 root rt 0 0 0 0 S 0,0 0,0 0:00.01 migratio+ 13 root 20 0 0 0 0 I 0,0 0,0 0:00.00 kworker/+ 14 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/0 15 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/1Anbei auch die Logs. Habe die 3. Stelle unserer IPAdressen geixt - nur falls das wer anmerken möchte;-)
Zum Verlauf: um 19 Uhr habe ich einen Neustart gemacht. Gegen 19:05 war yahka und shelly.0 schon rot. Um 19:12 shelly.1 rot. Zwischen 19:20-19:30 fritzdect.1 rot und zwischen 20:05-20:17 Uhr admin und um 20:18 Neustart admin.
Da der Admin ja nicht so schnell "abgeraucht" ist - habe ich auch angefangen, yahka wieder neu zu laden.
Ich weiß auch gar nicht genau, "wie" ich den Fehler benennen soll, weil ich so nichts seh... "Abrauchen", "Crash" ist ja auch falsch, da die Instanz noch läuft.
Wir hatten yahka z.B. mal mit cron neu starten lassen alle paar Minuten und wenn admin dann nicht erreichbar war, war yahka tatsächlich noch erreichbar.Als ich eben die Logs angesehen habe, habe ich gesehen, dass die Netzwerkkarte nicht "rund" erkannt wird beim booten... Also für meinen Geschmach nicht ganz rund...
Meine VMs laufen ja auf Xenserver. die haben auch xentools - die betreffen meine ich auch die Netzwerkkarte. Ich installier die mal, vielleicht bringt das auch was.
Denn sonst ist der einzige gleiche Nenner, dass es VMs auf Xenserver sind.
iobroker.2019-12-14.fehler.log@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
die "laufen" da dann immer noch
Nein, das ist nur die Einstellung im admin.
Wie man in Top sieht läuft nämlich nichts.
Da ist ein einziger iobroker Prozess, leider abgeschnitten welcher.@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
Meine VMs laufen ja auf Xenserver. die haben auch xentools - d
Das sagt mir leider nichts
Aber ich denke dass bei den VM die Ursache zu suchen ist. -
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
die "laufen" da dann immer noch
Nein, das ist nur die Einstellung im admin.
Wie man in Top sieht läuft nämlich nichts.
Da ist ein einziger iobroker Prozess, leider abgeschnitten welcher.@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
Meine VMs laufen ja auf Xenserver. die haben auch xentools - d
Das sagt mir leider nichts
Aber ich denke dass bei den VM die Ursache zu suchen ist.@Homoran
ah - dass ich das Fenster vergrößer, darüber hab ich gar nicht nachgedacht;-)
also wenn ich es jetzt mache zeigt der:top - 10:05:15 up 12:17, 2 users, load average: 0,00, 0,02, 0,00 Tasks: 102 total, 1 running, 101 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,4 us, 0,3 sy, 0,0 ni, 99,1 id, 0,1 wa, 0,0 hi, 0,0 si, 0,1 st MiB Mem : 1968,1 total, 276,4 free, 1439,9 used, 251,8 buff/cache MiB Swap: 1018,0 total, 1016,7 free, 1,2 used. 376,3 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 426 iobroker 20 0 1147692 322480 27236 S 1,0 16,0 6:46.23 iobroker.js-con 421 redis 20 0 51672 11440 3024 S 0,3 0,6 1:01.98 redis-server 441 root 20 0 792424 7196 1036 S 0,3 0,4 0:07.24 xe-daemon 544 iobroker 20 0 1077360 247416 26720 S 0,3 12,3 1:56.23 io.shelly.0 902 iobroker 20 0 1067476 238264 27024 S 0,3 11,8 1:52.61 io.shelly.1 962 root 20 0 11112 3304 2696 S 0,3 0,2 0:56.91 top 1 root 20 0 103816 9868 7824 S 0,0 0,5 0:00.69 systemdUnd vorher hatte ich auch mit
root@srvdeb3:~# ps -A | grep iobroker 426 ? 00:06:36 iobroker.js-congetestet, ob es lief und das tat es.
Ansich hätte ich ja für die einzelnen Instanzen ein terminated oder so erwartet, aber ich hab da nichts gesehen. Ich guck es mir nachher aber noch mal an, "lerne" ja auch noch dazu.
Aktuell ist es gerade, dass die Instanz "info" z.B. rot ist. In Top sieht es aber so aus:root@srvdeb3:~# top top - 10:10:49 up 12:23, 2 users, load average: 0,00, 0,02, 0,00 Tasks: 102 total, 2 running, 100 sleeping, 0 stopped, 0 zombie %Cpu(s): 2,0 us, 0,3 sy, 0,0 ni, 97,3 id, 0,2 wa, 0,0 hi, 0,0 si, 0,2 st MiB Mem : 1968,1 total, 741,5 free, 972,2 used, 254,4 buff/cache MiB Swap: 1018,0 total, 1016,7 free, 1,2 used. 844,0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 426 iobroker 20 0 1103576 279780 27236 S 5,3 13,9 6:51.58 iobroker.js-con 9209 iobroker 20 0 891316 57996 26964 S 1,0 2,9 0:00.62 io.yahka.0 9100 iobroker 20 0 722888 102296 28468 S 0,7 5,1 0:02.59 io.admin.0 9235 iobroker 20 0 700868 76684 26860 R 0,7 3,8 0:00.58 io.shelly.1 525 iobroker 20 0 940352 108420 27680 S 0,3 5,4 0:08.03 io.info.0Da hätte ich halt gedacht - müsste doch laufen - aber iobroker.admin zeigt den auf der Webseite eben "rot" an.
die sogenannten xentools, die ich gestern installiert hatte, brachten leider auch nicht den gewünschten Erfolg. Ebensowenig die Verschlüsselung.Ich installier parallel gerade rasbian auf meinem Pi. Mal sehen, ob da der Fehler auch passiert. Updates werden gerade installiert.
-
@Homoran
ah - dass ich das Fenster vergrößer, darüber hab ich gar nicht nachgedacht;-)
also wenn ich es jetzt mache zeigt der:top - 10:05:15 up 12:17, 2 users, load average: 0,00, 0,02, 0,00 Tasks: 102 total, 1 running, 101 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,4 us, 0,3 sy, 0,0 ni, 99,1 id, 0,1 wa, 0,0 hi, 0,0 si, 0,1 st MiB Mem : 1968,1 total, 276,4 free, 1439,9 used, 251,8 buff/cache MiB Swap: 1018,0 total, 1016,7 free, 1,2 used. 376,3 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 426 iobroker 20 0 1147692 322480 27236 S 1,0 16,0 6:46.23 iobroker.js-con 421 redis 20 0 51672 11440 3024 S 0,3 0,6 1:01.98 redis-server 441 root 20 0 792424 7196 1036 S 0,3 0,4 0:07.24 xe-daemon 544 iobroker 20 0 1077360 247416 26720 S 0,3 12,3 1:56.23 io.shelly.0 902 iobroker 20 0 1067476 238264 27024 S 0,3 11,8 1:52.61 io.shelly.1 962 root 20 0 11112 3304 2696 S 0,3 0,2 0:56.91 top 1 root 20 0 103816 9868 7824 S 0,0 0,5 0:00.69 systemdUnd vorher hatte ich auch mit
root@srvdeb3:~# ps -A | grep iobroker 426 ? 00:06:36 iobroker.js-congetestet, ob es lief und das tat es.
Ansich hätte ich ja für die einzelnen Instanzen ein terminated oder so erwartet, aber ich hab da nichts gesehen. Ich guck es mir nachher aber noch mal an, "lerne" ja auch noch dazu.
Aktuell ist es gerade, dass die Instanz "info" z.B. rot ist. In Top sieht es aber so aus:root@srvdeb3:~# top top - 10:10:49 up 12:23, 2 users, load average: 0,00, 0,02, 0,00 Tasks: 102 total, 2 running, 100 sleeping, 0 stopped, 0 zombie %Cpu(s): 2,0 us, 0,3 sy, 0,0 ni, 97,3 id, 0,2 wa, 0,0 hi, 0,0 si, 0,2 st MiB Mem : 1968,1 total, 741,5 free, 972,2 used, 254,4 buff/cache MiB Swap: 1018,0 total, 1016,7 free, 1,2 used. 844,0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 426 iobroker 20 0 1103576 279780 27236 S 5,3 13,9 6:51.58 iobroker.js-con 9209 iobroker 20 0 891316 57996 26964 S 1,0 2,9 0:00.62 io.yahka.0 9100 iobroker 20 0 722888 102296 28468 S 0,7 5,1 0:02.59 io.admin.0 9235 iobroker 20 0 700868 76684 26860 R 0,7 3,8 0:00.58 io.shelly.1 525 iobroker 20 0 940352 108420 27680 S 0,3 5,4 0:08.03 io.info.0Da hätte ich halt gedacht - müsste doch laufen - aber iobroker.admin zeigt den auf der Webseite eben "rot" an.
die sogenannten xentools, die ich gestern installiert hatte, brachten leider auch nicht den gewünschten Erfolg. Ebensowenig die Verschlüsselung.Ich installier parallel gerade rasbian auf meinem Pi. Mal sehen, ob da der Fehler auch passiert. Updates werden gerade installiert.
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
getestet, ob es lief und das tat es.
Das ist nur der Controller
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
zeigt den auf der Webseite eben "rot" an.
Was sagt dann mouseover?
-
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
getestet, ob es lief und das tat es.
Das ist nur der Controller
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
zeigt den auf der Webseite eben "rot" an.
Was sagt dann mouseover?
@Homoran said in Instanzen laufen nicht stabil (u.a. admin, yakha):
zeigt den auf der Webseite eben "rot" an.
Was sagt dann mouseover?
Verbunden mit Host "falsch"
Lebenszeichen "falsch"Hab danach auch schon versucht zu googlen, aber leider kaum Erfolg.
Einmal hatte ich n Treffer, dass das bei yahka öfter passieren sollte, wo die die Mac-Adresse anpassten - hatte ich auch schon gemacht, aber brachte auch keinen Erfolg. -
@Homoran said in Instanzen laufen nicht stabil (u.a. admin, yakha):
zeigt den auf der Webseite eben "rot" an.
Was sagt dann mouseover?
Verbunden mit Host "falsch"
Lebenszeichen "falsch"Hab danach auch schon versucht zu googlen, aber leider kaum Erfolg.
Einmal hatte ich n Treffer, dass das bei yahka öfter passieren sollte, wo die die Mac-Adresse anpassten - hatte ich auch schon gemacht, aber brachte auch keinen Erfolg.@kamikazemimmi bei yahka kann ich nicht helfen,
Ich warte mal auf eure pi Installation -
@kamikazemimmi bei yahka kann ich nicht helfen,
Ich warte mal auf eure pi Installation@Homoran said in Instanzen laufen nicht stabil (u.a. admin, yakha):
@kamikazemimmi bei yahka kann ich nicht helfen,
Ich warte mal auf eure pi Installationscheint ja aber bei den anderen instanzen auch zu sein - also egal, ob shelly oder info - in top tauchen die auf. Hab eben auch noch mit ps -A überprüft. Aber in der Admin-Oberfläche eben rot. starte ich die neu mit "iobroker restart yahka/shelly/admin" - ist die wieder grün und funktioniert wieder. Und ich finde halt nichts im Log - hatte gehofft, ich überseh was;-)
iobroker installation läuft gerade durch. Lassen die dann mal erst mal so laufen. Melde mich dazu,sobald ich da Aussagen zu machen kann.
-
@Homoran said in Instanzen laufen nicht stabil (u.a. admin, yakha):
@kamikazemimmi bei yahka kann ich nicht helfen,
Ich warte mal auf eure pi Installationscheint ja aber bei den anderen instanzen auch zu sein - also egal, ob shelly oder info - in top tauchen die auf. Hab eben auch noch mit ps -A überprüft. Aber in der Admin-Oberfläche eben rot. starte ich die neu mit "iobroker restart yahka/shelly/admin" - ist die wieder grün und funktioniert wieder. Und ich finde halt nichts im Log - hatte gehofft, ich überseh was;-)
iobroker installation läuft gerade durch. Lassen die dann mal erst mal so laufen. Melde mich dazu,sobald ich da Aussagen zu machen kann.
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
hatte gehofft, ich überseh was;-)
Ggf. die Instanzen von Admin, und die betroffenen auf logstufe debug stellen
Instanzen -> Epertenmodus-> spalte Logstufe -
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
hatte gehofft, ich überseh was;-)
Ggf. die Instanzen von Admin, und die betroffenen auf logstufe debug stellen
Instanzen -> Epertenmodus-> spalte Logstufe@Homoran
Hatte ich ja schon... Und logs hatte ich ja auch hochgeladen. Eben falls ich da was übersehe...
Nacheinander werden halt scheinbar alle Instanzen irgendwann rot - auch der admin. Und auf meinen aneren Testinstallationen hatte ich dann eben nur die Grundinstallation, aber da war spätestens nach 2 Stunden auch alles rot - also auch der Admin nicht mehr erreichbar. Bisher ist der pi noch erreichbar und alles grün. Mal sehen.
Was ich beim PI allerdings anders gemacht habe: ich habe einen Standort bei der ersten Einrichtung eingegeben - das habe ich bei den anderen Installationen nicht gemacht.
Aber gut, erst mal abwarten. -
@Homoran
Hatte ich ja schon... Und logs hatte ich ja auch hochgeladen. Eben falls ich da was übersehe...
Nacheinander werden halt scheinbar alle Instanzen irgendwann rot - auch der admin. Und auf meinen aneren Testinstallationen hatte ich dann eben nur die Grundinstallation, aber da war spätestens nach 2 Stunden auch alles rot - also auch der Admin nicht mehr erreichbar. Bisher ist der pi noch erreichbar und alles grün. Mal sehen.
Was ich beim PI allerdings anders gemacht habe: ich habe einen Standort bei der ersten Einrichtung eingegeben - das habe ich bei den anderen Installationen nicht gemacht.
Aber gut, erst mal abwarten.@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
ich habe einen Standort bei der ersten Einrichtung eingegeben - das habe ich bei den anderen Installationen nicht gemacht.
Das macht nix.
Der wird für geoposition und astrofunktionen benötigt@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
Bisher ist der pi noch erreichbar und alles grün. Mal sehen.
Ich denke es liegt wirklich an deiner VM Konfiguration
-
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
ich habe einen Standort bei der ersten Einrichtung eingegeben - das habe ich bei den anderen Installationen nicht gemacht.
Das macht nix.
Der wird für geoposition und astrofunktionen benötigt@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
Bisher ist der pi noch erreichbar und alles grün. Mal sehen.
Ich denke es liegt wirklich an deiner VM Konfiguration
@Homoran said in Instanzen laufen nicht stabil (u.a. admin, yakha):
Ich denke es liegt wirklich an deiner VM Konfiguration
Ja das wäre sonst der einzige gleiche Nenner. Habe ja auch 2 unterschiedliche Debian und auch mal ubuntu getestet - und immer gleiches Ergebnis (wobei ich den Fehler total seltsam finde !!!)
Aber gut - noch läuft alles auf n Pi. Mal abwarten. -
@Homoran said in Instanzen laufen nicht stabil (u.a. admin, yakha):
Ich denke es liegt wirklich an deiner VM Konfiguration
Ja das wäre sonst der einzige gleiche Nenner. Habe ja auch 2 unterschiedliche Debian und auch mal ubuntu getestet - und immer gleiches Ergebnis (wobei ich den Fehler total seltsam finde !!!)
Aber gut - noch läuft alles auf n Pi. Mal abwarten.Also aktueller Stand ist, dass tatsächlich auf dem Pi noch alles läuft. Instanzen immer noch grün - mittlerweile auch yahka und shelly eingerichtet.
Also wird iobroker erst mal wohl auf dem Pi laufen - werde aber trotzdem gucken, ob ich Linux in einer VM auf dem Xenserver irgendwie mit iobroker zum Laufen bekomme. Ergebnisse werde ich hier weiter mitteilen. -
Also aktueller Stand ist, dass tatsächlich auf dem Pi noch alles läuft. Instanzen immer noch grün - mittlerweile auch yahka und shelly eingerichtet.
Also wird iobroker erst mal wohl auf dem Pi laufen - werde aber trotzdem gucken, ob ich Linux in einer VM auf dem Xenserver irgendwie mit iobroker zum Laufen bekomme. Ergebnisse werde ich hier weiter mitteilen.@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
auf dem Pi noch alles läuft
so muss es sein und ist zu erwarten!
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
ob ich Linux in einer VM auf dem Xenserver
Ich (und viele andere) habe noch iobroker in VMs mit Debian unter Proxmox auf einem NUC problemlos laufen.
Was hat denn der (mir unbekannte) XenServer für eine Hardware?
Was hast du da für ein Debian draufIrgendwo da muss das Problem stecken
-
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
auf dem Pi noch alles läuft
so muss es sein und ist zu erwarten!
@kamikazemimmi sagte in Instanzen laufen nicht stabil (u.a. admin, yakha):
ob ich Linux in einer VM auf dem Xenserver
Ich (und viele andere) habe noch iobroker in VMs mit Debian unter Proxmox auf einem NUC problemlos laufen.
Was hat denn der (mir unbekannte) XenServer für eine Hardware?
Was hast du da für ein Debian draufIrgendwo da muss das Problem stecken
@Homoran
der Xenserver auf dem ich die iobroker-Installationen hatte hat einen Xeon CPU. Auf dem ist auch die neueste Xenserver 8.0 Version drauf. Xenserver hat verschiedene Templates für VM - also es gibt noch einiges, was ich jetzt testen werde:-
Installation auf einem anderen Linux-Template
-
Installation auf Xenserver 7.5
-
Installation auf einem Xenserver mit i5 CPU
Also generell setze ich Xenserver in den unterschiedlichsten Szenarien ein. Wichtig war ansich immer, dass ich beim Chipsatz auf vt-d unterstützung achte und das auch aktivier.
Ich hatte aber auch schon mal bei früheren Xenserver Versionen, dass manche Maschine nicht "umziehen" wollte - startete dann einfach nicht. Oder ein Dienst nicht (also bei einer Windows VM).
Hoffe, dass ich da schnell eine Lösung finde. Fände es gut, wenn ich den iobroker eben auch virtuell hätte und nicht noch ein Gerät extra an wäre;-)Proxmox kenne ich noch gar nicht. Gucke ich mir aber auch noch mal an.
-
765
Online32.6k
Benutzer82.2k
Themen1.3m
Beiträge