UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[apollon77]

@madjack84 Also ja im Log sehe ich zuerst zwei "saubere" stopps.
Dann sehe ich aber 23:11:32.366 - 23:13:22.924 einen "plötzlichen stop" ... Da sieht man nur den restart danach und bei dem sind BEIDE Files kaputt ... das sollte an sich niemals passieren und dies ist auch hier nicht ersichtlich wie das passieren konnte.

2022-01-26 23:13:23.100 - error: host.ioalbrecht-Server Cannot load /opt/iobroker/iobroker-data/objects.json: /opt/iobroker/iobroker-data/objects.json: Unexpected end of JSON input. We try last Backup!
2022-01-26 23:13:23.109 - error: host.ioalbrecht-Server Cannot load /opt/iobroker/iobroker-data/objects.json.bak: /opt/iobroker/iobroker-data/objects.json.bak: Unexpected end of JSON input. Continue with empty dataset!

Bei States ist "nur" das letzte Hauptfile kaputt, da war aber das Backup File wohl ok

2022-01-26 23:13:23.214 - error: host.ioalbrecht-Server Cannot load /opt/iobroker/iobroker-data/states.json: /opt/iobroker/iobroker-data/states.json: Unexpected end of JSON input. We try last Backup!

Ich überlege nochmal was man besser machen kann

[madjack84]

@apollon77 dann ist mir der vielleicht durchgerutscht :/ möchte ich nicht ausschließen um die Zeit. Hoffe ich kann da irgendwie helfen.
Kann ich irgendetwas aktivieren um das log zu verbessern?

[apollon77]

@madjack84 Also am Ende kann es nur sein das du in einen Absoluten edge case gelaufen bist. Der wäre: Durch irgendwas war dein .bak File kaputt und jetzt ist der controller so "früh" nach einem Start abgestürzt da er genau ins erste Schreiben der Db reingerannt ist. Damit sind dann beide Files kaputt.

Ich habe für js-controller 4.0 was eingebaut um das zu verhindern ...

[madjack84]

@apollon77 guten Morgen, über Nacht hat sich Proxmox mal aufgehangen :-1: . Neustart.... und leider wollte iobroker auch wieder nicht starten auf der Suche nach dem Host View :(
Das ist leider das dritte mal die Woche :( Auch bei nem bekannten ists gestern nicht mehr hochgefahren. Gleiches Thema.

Ausser Neustarts vermeiden: Kann ich irgendetwas tun um das zu verhindern? bzw ist ein fix absehbar?

[Thomas Braun]

@madjack84 sagte in Mini-HowTo: Cannot find view "system" for search "host":

über Nacht hat sich Proxmox mal aufgehangen

Schau warum es das tut.

[apollon77]

@madjack84 Hm ... Dann Infos bitte ... js-controller Version? Logs?

Und ja ... "Proxmox hat sich aufgehangen" ist mehr als Strange

[arteck]

@madjack84 sagte in Mini-HowTo: Cannot find view "system" for search "host":

guten Morgen, über Nacht hat sich Proxmox mal aufgehangen

wat.. ist klar.. LOGS von dem Proxmox hätte ich gerne gesehen

[madjack84]

@arteck @apollon77 Thomas Braun

Gerne... ja die PRoxmox Abstürze nerven mich auch tierisch. Dachte erst das liegt am LXC Container. PAssierte meistens wenn ich mich an der Iobroker WebUI gearbeitet hab.
Dann hab ich umgestellt auf VM... nun wieder der Absturz. Hier das aktuelle System:

Proxmox stürzt so ab, dass alle Container nicht mehr erreichbar sind inkl. Proxmox Interface. Per SSH kann man sich einloggen, aber die simpelsten Befehle sind nicht mehr möglich. Ich fürchte da hängt sich der Kernel irgendwie auf. Ich hab auch schon gelesen, dass es an meinen Kingston RAM Riegeln liegen könnte. Da gibts mangelhafte Chargen.

Hier die beiden Syslogs. Abends hab ich noch dran gearbeitet... morgens ging dann nichts mehr 07:18 dann der Hardreset am NUC.

syslog.1 syslog

bin dankbar für jeden Hinweis, möchte allerdings hier nicht den Thread vergewaltigen. Das search for host view Thema ist sehr wichtig und dort stellt sich mir die primäre Frage: Wie kann das verhindert werden? Gefühlt kann ich das auch reproduzieren (auch wenn ich das nicht will) um euch irgendwie zum debuggen zu helfen. Leider ist mein Latein hier weit entfernt vom Hacker Abzeichen ;)

[Thomas Braun]

@madjack84

Nur eine CPU zugewiesen? Bei MultiCores könnte das zu wenig sein.

[Homoran]

@madjack84 sagte in Mini-HowTo: Cannot find view "system" for search "host":

Hier das aktuelle System

das ist doch nicht das gesamte proxmox!

was stürzt denn jetzt ab?

[madjack84]

@homoran das ist das syslog der Basismaschine vom 30.ten und 31. ten. Was genau kann ich noch hochladen? Sorry, bin da etwas überfragt welches log. Hast du evtl ein folder?
Es stürzen alle 4 vms ab.... keine ist mehr erreichbar... :(

@Thomas Braun: Dachte das sollte reichen für iob... die CPU gähnt sich immer einen ab :D dann geb ich ihm mal nen zweiten ;) Danke für den Hinweis

EDIT: mit "das ist leider das 3te mal diese Woche" meinte ich nicht Proxmox, sondern das search for host view thema. Einmal wars ein Stromausfall, einmal hab ich den NUC neu gestartet und einmal ist der NUC abgeschmiert. 3 unterschiedliche Gründe... gleiches Ergebnis :(

[Thomas Braun]

@madjack84 sagte in Mini-HowTo: Cannot find view "system" for search "host":

3 unterschiedliche Gründe...

Nein, der Grund ist immer der gleiche:
ioBroker wurde nicht ordentlich gestoppt.

[madjack84]

@thomas-braun jo, leider passiert das ohne dass ich das will, bzw verhindern kann.

Grade wollte ich BAckups der proxmox Maschinen ziehen.... Absturz :( da ist gröber was im Argen :(

Das log ist mal wieder kommentarlos... war mitten auf der Kommandozeile und wollte grade die backups ziehen. Kurz davor hab ich ein Backup einer Maschine angeworfen.

Spoiler

Jan 31 21:12:01 proxmox systemd[1]: pvesr.service: Succeeded.
Jan 31 21:12:01 proxmox systemd[1]: Started Proxmox VE replication runner.
Jan 31 21:12:31 proxmox pvedaemon[1104]: root@pam successful auth for user 'root@pam'
Jan 31 21:13:00 proxmox systemd[1]: Starting Proxmox VE replication runner...
Jan 31 21:13:01 proxmox systemd[1]: pvesr.service: Succeeded.
Jan 31 21:13:01 proxmox systemd[1]: Started Proxmox VE replication runner.
Jan 31 21:14:00 proxmox systemd[1]: Starting Proxmox VE replication runner...
Jan 31 21:14:01 proxmox systemd[1]: pvesr.service: Succeeded.
Jan 31 21:14:01 proxmox systemd[1]: Started Proxmox VE replication runner.
Jan 31 21:14:29 proxmox pvedaemon[1103]: root@pam starting task UPID:proxmox:00002B2A:004C9633:61F84325:vzdump:108:root@pam:
Jan 31 21:14:29 proxmox pvedaemon[11050]: INFO: starting new backup job: vzdump 108 --node proxmox --remove 0 --compress zstd --mode snapshot --storag$
Jan 31 21:14:29 proxmox pvedaemon[11050]: INFO: Starting Backup of VM 108 (qemu)
Jan 31 21:21:04 proxmox systemd-modules-load[384]: Inserted module 'iscsi_tcp'
Jan 31 21:21:04 proxmox dmeventd[407]: dmeventd ready for processing.
Jan 31 21:21:04 proxmox systemd-modules-load[384]: Inserted module 'ib_iser'
Jan 31 21:21:04 proxmox systemd-modules-load[384]: Inserted module 'vhost_net'
Jan 31 21:21:04 proxmox systemd[1]: Starting Flush Journal to Persistent Storage...
Jan 31 21:21:04 proxmox lvm[407]: Monitoring thin pool pve-data-tpool.
Jan 31 21:21:04 proxmox systemd[1]: Started udev Kernel Device Manager.
Jan 31 21:21:04 proxmox lvm[390]: 15 logical volume(s) in volume group "pve" monitored
Jan 31 21:21:04 proxmox systemd[1]: Started Flush Journal to Persistent Storage.
Jan 31 21:21:04 proxmox systemd[1]: Started udev Coldplug all Devices.
Jan 31 21:21:04 proxmox systemd[1]: Starting Helper to synchronize boot up for ifupdown...
Jan 31 21:21:04 proxmox systemd[1]: Starting udev Wait for Complete Device Initialization...
Jan 31 21:21:04 proxmox systemd-udevd[439]: Using default interface naming scheme 'v240'.
Jan 31 21:21:04 proxmox systemd-udevd[439]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jan 31 21:21:04 proxmox systemd-udevd[448]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Jan 31 21:21:04 proxmox systemd[1]: Found device KINGSTON SA2000M8250G 2.

Proxmos hat sich also nachts aufgehangen weil ich ein Backup angestoßen hatte.

UND: Nr4.... iobroker wollte wieder nicht starten. Es ist also voll reproduzierbar. Nun mag es heißen, dass mein queres Proxmox dran schuld ist... auf dem RPI4 ists mir allerdings auch passiert :(

Ich klage niemanden an, bitte nicht falsch verstehen. Ich möchte euch Debugmöglichkeiten anbieten.

[Thomas Braun]

@madjack84

Aber du verwechselst offenbar Ursache und Wirkung.
Dein Betriebssystem läuft nicht stabil und zersäbelt dadurch den ioBroker.

[madjack84]

@thomas-braun das heißt, dass mein im Dezember aufgesetzter RPI nicht stabil war, meine beiden Proxmox Maschinen nicht stabil sind, die von meinem Kumpel nicht stabil ist und die anderen Editoren aus diesem Thread haben auch nur schlechte Installationen?

Ich fürchte es gibt verschiedenste Ursachen, evtl bei jedem unterschiedlich.... aber iobroker zeigt oft die gleiche (besorgniserregende) Reaktion :(
Wie gesagt: KEINE Anklage - ein Angebot. Ich weiß man tendiert dazu sich angegriffen zu fühlen. Das ist aber 0 Komma 0 meine Intention.

Ich setze neu auf... iobroker wieder auf den RPI und Proxmox bekommt ne ordentliche Neuinstallation direkt auf 7. mich nervt das ja selbst...

[apollon77]

@madjack84 Also wenn dein System so "abkachelt" ist der ioBroker drauf dein kleinstes Problem ;-) Fixe erstmal das Thema

[madjack84]

@apollon77 bin ich völlig bei dir. Höchste Alarmstufe. der RPI4 hats aber leider auch gezeigt. Bei mir kommen halt 2 Dinge grade blöd zusammen. Bin dran und berichte

[wendy2702]

@madjack84 sagte in Mini-HowTo: Cannot find view "system" for search "host":

KINGSTON SA2000M8250G 2

Ich hatte bei einer meiner Proxmox installationen mit einer Kingston SSD ähnliche Probleme.

Ursache war bei mir letztendlich das Anschlusskabel. Das hast du natürlich jetzt nicht aber möglicher weise liegt es wirklich am Kingston Device.

Geht das log nicht irgendwann wieder weiter?

Konnte man den loglevel unter Proxmox nicht auch erhöhen?

Mal wie beim PI mit DMESG geschaut ob dort etwas auffälliges steht.

[Thomas Braun]

@madjack84 sagte in Mini-HowTo: Cannot find view "system" for search "host":

Ich weiß man tendiert dazu sich angegriffen zu fühlen.

Ich fühle mich nicht angegriffen. Warum auch.
Aber dein Betriebssystem macht halt die Grätsche und reißt den ioBroker unsanft mit.

[BananaJoe]

Ich habe am Wochenende zufällig bei einem Freund euch eine ioBroker-Installation durchgeführt. Und ich habe da so meine ganz eigene Theorie warum ioBroker "dauernd kaputt geht" nach Abstürzen, Reset oder Stromausfällen:

Hier im Forum sind wir neulich darauf gekommen das der ioBroker die objects.json (ob auch die states.json weis ich nicht) regelmäßig auf Festplatte schreibt.

Bei meinem Freund habe ich mir die Einstellung in der

/opt/iobroker/iobroker-data/iobroker.json

mit dem Namen

"writeFileInterval": 5000,

steht somit auf 5 Sekunden ab Werk. "Doof" ist wenn das System weg ist während er schreibt. Und bei alle 5 Sekunden sind die Chancen ziemlich gut das es schiefgeht - finde ich, immerhin 12 mal die Minute. Insbesondere wenn die Datei groß und der Datenträger ggf. langsam ist und er ggf. sowieso mehr als 1 Sekunde zum schreiben braucht.

In meinem (USV geschützten) System habe ich den Wert auf 10 Minuten gesetzt. bei meinem Freund erst einmal auf 60 Sekunden.