broker mit und ohne Fehlermeldung nicht erreichbar
-
Ich vermute, da ist die alte Installation auf einem anderen host(name) gelaufen.
iobroker stop iobroker host this iobroker start iobroker list adapters iobroker list instances -
pi@homeserver:~ $ iobroker stop pi@homeserver:~ $ iobroker host this A host with the name "homeserver" already exists! pi@homeserver:~ $ iobroker start pi@homeserver:~ $ iobroker list adapters system.adapter.admin : admin - v5.2.3 system.adapter.discovery : discovery - v2.7.3 system.adapter.history : history - v1.9.14 system.adapter.javascript : javascript - v5.2.13 system.adapter.radar2 : radar2 - v2.0.3 pi@homeserver:~ $ iobroker list instances + system.adapter.admin.0 : admin : homeserver - enabled, port: 8081, bind: 0.0.0.0, run as: admin + instance is alive pi@homeserver:~ $Mir fällt gerade auf, ich könnte ja mal den Fehler im Browser anzeigen:
-
Von SSL hab ich keine Ahnung. Meine Installation kommt ohne aus.
-
@Thomas-Braun Das ist schade....dann wird wohl nur das Backup helfen, oder hat @Homoran noch eine Idee?
-
@philipp-dorn sagte in broker mit und ohne Fehlermeldung nicht erreichbar:
hat @Homoran noch eine Idee?
was das SSL angeht überhaupt nicht - damit kenne ich mich gar nicht aus.
Für die anderen Punkte könnte man vielleicht nochmal das mini HowTo durchjagen, wenn es dazu nicht schon zu spät ist, da jede Änderung einen älteren Eintrag rauswirft und irgendwann keine heilen Zustände mehr existieren.
Alles im Allem wäre jetzt wohl die Zeit für ein Restore (auf einem aktuellen System)
Dabei aber jetzt unbedingt auf den Hostnamen achten
Der sollte identisch mit dem im Backup sein -
@homoran Okay, mache ich, Hostname ist seit Monaten, wenn nicht sogar Jahren nicht geändert.
Danke für Eure Hilfe!
-
Backup restored, funzt wieder alles. Auf ein neues
-
OOOOOOKAY?!?!?
Jetzt bin ich verwirrt. Ich habe ja wie bereits erwähnt das Backup restored, und auch extra nicht das letzte von vor einem Monat genommen sondern ein etwas älteres, von dem ich weiß, dass es ohne Probleme lief.
Gestern Abend ist nun der gleiche Error wieder passiert, iobroker ist nicht mehr erreichbar. Ich habe nach dem Restore wohlgemerkt NICHTS an iobroker gemacht....
Parallel dazu läuft auf dem gleichen Raspberry mein Unify Server ohne Probleme, nur iobroker ist wieder nicht erreichbar.
Bevor ich jetzt die Standardanleitung wieder durchgehe nun vorher die Frage - irgendwelche Anregungen für das Vorgehen? Oder soll ich das oben beschriebene einfach nochmal exakt so durchführen? Ich würde jetzt als erstes nochmal "iobroker fix" probieren, auch wenn ich nicht glaube, dass es das Problem löst. Spannend wäre jetzt ja mal, die Quelle des Fehlers zu finden....
-
|Arbeitsspeicher:| 1GB |
Unify-ServerUnd da quetscht du auch noch neben den iobroker noch weiteren Kram? Das ist ohnehin schon knapp bemessen mit dem einen GB.
-
@thomas-braun Ja, grundsätzlich richtig, allerdings in der RAM übersicht war es nie so, dass ich da in einen kritischen Bereich kam....
Hat ja auch wirklich mittlerweile Jahre funktioniert....
pi@homeserver:~ $ free total used free shared buff/cache available Mem: 996100 620888 100256 1740 274956 345296 Swap: 1023996 209664 814332 -
Der Speicherbedarf ist in den letzten Versionen des iobrokers aber auch gestiegen. Was 'vor Jahren' ging muss heute nicht unbedingt noch passen.
Ich vermute, dass der Kiste der Spielraum ausgeht. Vielleicht beim nächtlichen Backup. -
-
@thomas-braun Backup mache ich manuell, also beim Backup kanns nicht sein...
Also empfiehlst du nen Raspi4? Ich habe eh schon seit längerem Überlegt ein kubernetes Cluster aus zwei Raspis 4 zu erstellen und alles dadrin zu hosten. Von der Leistung her, müsste der Raspi 4 das ja locker schaffen.
pi@homeserver:~ $ free -ht --mega total used free shared buff/cache available Mem: 972M 329M 535M 0.0K 107M 596M Swap: 999M 331M 668M Total: 2.0G 661M 1.2G -
Ich empfehle mehr RAM als 1GB. Ob das jetzt ein Raspberry ist oder was anderes ist egal.
Edith: Dein Swap ist komisch...
-
@thomas-braun Pro Node oder pro Cluster? Ich könnte natürlich (aufgrund der aktuell nicht bekommbaren Raspis 4 einen zweiten 3er als Node hinzufügen. Dann wäre es mehr Ram. Zukunfsträchtig ist es aber nicht auch nicht sehr lange.
-
@thomas-braun said in broker mit und ohne Fehlermeldung nicht erreichbar:
Edith: Dein Swap ist komisch...
Definiere komisch?
-
Komisch groß, komisch zu voll.
Du hast ein Problem mit zu wenig RAM.Mein System:
echad@chet:~ $ free -ht --mega total used free shared buff/cache available Mem: 7.8G 2.1G 2.6G 0.0K 3.2G 5.6G Swap: 99M 0B 99M Total: 7.9G 2.1G 2.7G -
@thomas-braun Okay, das stimmt scheinbar. Aber ist nicht genau dafür eigentlich der Swap da, damit eben mein System nicht abschmiert?
Ich schaue mich nach einem Raspi 4 um, lege ein Kubernetes-Cluster an und werde da Unify und iobroker als Container laufen lassen. Gibts Erfahrungen mit iobroker als Container?
-
@philipp-dorn sagte in broker mit und ohne Fehlermeldung nicht erreichbar:
Aber ist nicht genau dafür eigentlich der Swap da, damit eben mein System nicht abschmiert?
Jein. Swap ist der Notüberlauf, wenn der in letzter Verzweiflung genutzt werden muss ist aber schon das System übervoll. Wenn swap dann auch ausgereizt ist geht gar nix mehr und der Sensenmann (oom-reaper) senst sich im Selbsterhaltungstrieb durch das System und säbelt Prozesse weg.
Gibts Erfahrungen mit iobroker als Container?
Bin ich kein Freund von. Geht aber prinzipiell.
-
@thomas-braun Was merkwürdig ist, dass ich jetzt nicht wirklich einen Prozess sehe, der den RAM so überbügelt.....
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11539 iobroker 20 0 448804 257160 18696 R 87.6 25.8 2:09.13 iobroker.js-con 11650 iobroker 20 0 157188 35892 18896 S 10.7 3.6 0:03.22 node 11686 iobroker 20 0 157368 36044 18836 S 9.7 3.6 0:03.22 node 11721 iobroker 20 0 156884 32808 18852 S 9.1 3.3 0:03.28 node 888 unifi 20 0 1331416 83620 5316 S 7.7 8.4 3:32.63 java 11735 iobroker 20 0 158436 34288 18872 S 6.7 3.4 0:03.64 node 11581 iobroker 20 0 283308 134608 18808 S 5.4 13.5 0:16.93 io.admin.0 1603 root 0 -20 0 0 0 I 2.0 0.0 0:15.72 kworker/0:0H-mmc_complete 11637 iobroker 20 0 161692 40252 18816 S 2.0 4.0 0:03.77 node 11644 iobroker 20 0 159292 38160 18840 S 2.0 3.8 0:03.07 node 11652 iobroker 20 0 158996 37652 18832 S 2.0 3.8 0:02.99 node 11664 iobroker 20 0 162184 41088 18788 S 2.0 4.1 0:04.21 node 11693 iobroker 20 0 158176 34932 18872 S 2.0 3.5 0:03.46 node 11694 iobroker 20 0 157188 31384 18788 S 2.0 3.2 0:03.39 node 11707 iobroker 20 0 160080 37724 18864 S 2.0 3.8 0:03.31 node 11671 iobroker 20 0 163256 42456 18812 S 1.7 4.3 0:03.73 node 11674 iobroker 20 0 161232 39296 18788 S 1.7 3.9 0:03.69 node 11709 iobroker 20 0 162424 41336 18940 S 1.7 4.1 0:04.00 node 92 root 20 0 0 0 0 I 1.3 0.0 0:09.39 kworker/u8:1-events_unbound 11614 iobroker 20 0 161008 22716 18192 S 1.3 2.3 0:03.77 node 11120 root 20 0 0 0 0 I 1.0 0.0 0:00.90 kworker/0:1-events 11 root 20 0 0 0 0 S 0.7 0.0 0:04.76 ksoftirqd/0 84 root 0 -20 0 0 0 I 0.7 0.0 0:08.16 kworker/1:1H-kblockd 1032 unifi 20 0 1367868 10592 7640 R 0.7 1.1 0:48.04 mongod 6517 root 0 -20 0 0 0 I 0.7 0.0 0:04.10 kworker/2:0H-kblockd 11598 iobroker 20 0 157976 22176 18388 S 0.7 2.2 0:03.25 node 11631 pi 20 0 10340 2008 1580 R 0.7 0.2 0:00.49 top 610 root 20 0 917012 4288 1404 S 0.3 0.4 0:06.70 containerd 4630 pi 20 0 12204 1740 1588 S 0.3 0.2 0:00.16 sshd 9536 root 0 -20 0 0 0 I 0.3 0.0 0:00.89 kworker/3:2H-kblockd 11795 root 20 0 0 0 0 I 0.3 0.0 0:00.02 kworker/2:0-mm_percpu_wq 1 root 20 0 34780 2364 1968 S 0.0 0.2 0:10.30 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.07 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_gp 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq 9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tasks_rude_ 10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tasks_trace 12 root 20 0 0 0 0 I 0.0 0.0 0:05.06 rcu_sched 13 root rt 0 0 0 0 S 0.0 0.0 0:00.08 migration/0 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/1 16 root rt 0 0 0 0 S 0.0 0.0 0:00.04 migration/1 17 root 20 0 0 0 0 S 0.0 0.0 0:01.89 ksoftirqd/1 20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2 21 root rt 0 0 0 0 S 0.0 0.0 0:00.10 migration/2 22 root 20 0 0 0 0 S 0.0 0.0 0:01.96 ksoftirqd/2 25 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/3 26 root rt 0 0 0 0 S 0.0 0.0 0:00.07 migration/3 27 root 20 0 0 0 0 S 0.0 0.0 0:01.97 ksoftirqd/3 30 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs 31 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns 34 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kauditd 36 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khungtaskd 37 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_reaper 38 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 writeback 39 root 20 0 0 0 0 S 0.0 0.0 0:10.13 kcompactd0 57 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kblockd 58 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 blkcg_punt_bio 59 root -51 0 0 0 0 S 0.0 0.0 0:00.00 watchdogd 62 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rpciod 63 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/u9:0-hci0 64 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 xprtiod 65 root 20 0 0 0 0 S 0.0 0.0 0:44.73 kswapd0 66 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 nfsiod 69 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 iscsi_eh 70 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 iscsi_destroy 71 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 dwc_otg 73 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 DWC Notificatio 75 root 1 -19 0 0 0 S 0.0 0.0 0:00.00 vchiq-slot/0Wenn ich das so eine Zeit überwache, ist das Maximum der Gefühle ca. 700MB in Use (aber auch nur mal kurzer Peak, ansonsten so ca. 250MB). Warum belegt er dann den Swap?
