ioBroker nicht erreichbar nach Neustarts. Admin.0 fehlt?

ChrisPrefect

@thomas-braun deine Antworten bringen mich leider nicht weiter und gehen am Thema vorbei.

Wie kann ioBroker sich so aufhängen? Einen Stromausfall kann es immer geben. Damit sollte auch ioBroker klar kommen, so wie jedes andere System hier.

Ich möchte herausfinden, was genau kaputt ist und das reparieren.

Wenn das Dateisystem kaputt wäre, würde sich Linux ja drum kümmern und ioBroker würde davon nichts merken.

Config-Files wurden auch keine geschrieben, daran kann es auch nicht liegen.

Kann es sein, dass die Objekt-Datenbank kaputt ist? Wie kann ich das kontrollieren? Würde das diese Symptome zeigen? Dann könnte ich die aus backitup extrahieren?

ChrisPrefect

@skorpil die Sicherungspunkte muss man manuell im Ausgeschalteten Zustand anlegen. Das kann ich also nur sehr selten machen.

Das neueste wäre das backitup-Backup. Aber das möchte ich erst probieren, wenn ich sicher bin, dass diese Installation nicht mehr zu retten ist. Was ich mir eigentlich nicht vorstellen kann, schliesslich wurde nur die VM mal abgestellt...

Thomas Braun

@chrisprefect

iobroker status
iobroker list adapters
iobroker list instances

fastfoot

@chrisprefect sagte in ioBroker nicht erreichbar nach Neustarts. Admin.0 fehlt?:

@skorpil die Sicherungspunkte muss man manuell im Ausgeschalteten Zustand anlegen. Das kann ich also nur sehr selten machen.

Das neueste wäre das backitup-Backup. Aber das möchte ich erst probieren, wenn ich sicher bin, dass diese Installation nicht mehr zu retten ist. Was ich mir eigentlich nicht vorstellen kann,

schliesslich wurde nur die VM mal abgestellt...

und das hat dir ja auch nur dein System etwas zerschossen.

Angenommen es wäre die Objektdatenbank. Woher willst du wissen dass nicht andere Dateien betroffen sind, was du evtl. erst viel zu spät bemerkst. Wenn dir dein System so wichtig ist dann erstelle ne neue VM, spiel das Backup ein und gut ist. Wenn nicht hast du noch die alte VM

ChrisPrefect

@thomas-braun

root@ioBrokerVM:~# iobroker status
iobroker is running on this host.


Objects type: file
States  type: file
root@ioBrokerVM:~# iobroker list adapters
system.adapter.admin                   : admin          - v4.2.1
root@ioBrokerVM:~# iobroker list instances
+ system.adapter.admin.0                  : admin                 : ioBrokerVM                               -  enabled, port: 8089, bind: 0.0.0.0, run as: admin

+ instance is alive

die eine admin-instanz ist die, die ich nachträglich angelegt hatte.

Sieht schon recht krass aus, nicht? Was kann da passiert sein?

Die installierten Adapter zeigt er aber z.B. bei einem update alle korrekt an:

root@ioBrokerVM:~# iobroker update
Used repository: beta
hash unchanged, use cached sources
update done
Adapter    "accuweather"   : 1.1.5
Adapter    "adb"           : 0.0.5
Adapter    "admin"         : 4.2.1    , installed 4.2.1
Adapter    "alarm"         : 2.0.0
Adapter    "alexa2"        : 3.8.1    , installed 3.8.1
Adapter    "alias-manager" : 1.0.2
Adapter    "alpha2"        : 1.0.0
Adapter    "amazon-dash"   : 1.1.0
Adapter    "artnet"        : 1.2.2
Adapter    "asterisk"      : 1.0.6
Adapter    "asuswrt"       : 1.0.1
Adapter    "b-control-em"  : 0.2.1
Adapter    "backitup"      : 2.1.2    , installed 2.1.2
Adapter    "beckhoff"      : 1.4.0
Adapter    "benq"          : 0.2.5
Adapter    "binance"       : 1.1.3
Adapter    "ble"           : 0.12.0
Adapter    "blink4home"    : 0.1.1
Adapter    "bmw"           : 1.4.0
Adapter    "boblight"      : 0.0.1
Adapter    "bosesoundtouch": 0.9.3
Adapter    "botvac"        : 1.0.0
Adapter    "bring"         : 1.7.7
Adapter    "broadlink2"    : 2.1.5
Adapter    "bsblan"        : 0.2.2
Adapter    "bshb"          : 0.1.13
Adapter    "bydbatt"       : 1.0.4
Adapter    "calendar"      : 1.2.0
Adapter    "cameras"       : 0.1.3
Adapter    "canbus"        : 1.1.3
Adapter    "cec2"          : 0.1.0
Adapter    "chromecast"    : 2.3.1
Adapter    "cloud"         : 4.0.10   , installed 4.0.10
Adapter    "comfoair"      : 1.1.3
Adapter    "contact"       : 1.1.3
Adapter    "contactid"     : 1.0.2
Adapter    "coronavirus-statistics": 0.7.0-4
Adapter    "corrently"     : 0.0.2
Adapter    "countdown"     : 1.1.0
Adapter    "cul"           : 1.3.5
Adapter    "daikin"        : 1.3.0
Adapter    "daswetter"     : 3.0.5
Adapter    "deconz"        : 1.3.11   , installed 1.3.11
Adapter    "denon"         : 1.10.4
Adapter    "device-reminder": 1.0.6
Adapter    "devices"       : 0.3.16
Adapter    "digitalstrom"  : 2.2.0
Adapter    "discovergy"    : 0.5.7
Adapter    "discovery"     : 2.6.2    , installed 2.6.2
Adapter    "divera247"     : 0.0.10
Adapter    "doorbird"      : 0.1.5
Adapter    "doorio"        : 1.1.4

etc...

ChrisPrefect

@fastfoot Ich hatte glaube ich wirklich noch nie den Fall, dass ein System nach einem Stromausfall kaputt war. Windows habe ich sicher schon 200 Mal per Netzschalter ausgeschaltet oder Notebooks oft per langem gedrückt-halten des Power-Buttons ausschalten müssen. Noch nie hatte das irgend eine Auswirkung. In diesem Fall bin ich davon ausgegangen, dass VirtualBox die VMS per ACPI herunterfährt. Anscheinend ist das nicht der Fall gewesen.

ioBroker hat sich bei mir aber schon 3-4 Mal zerschossen. Ob auf dem Raspi oder nun in der VM. Irgend etwas scheint da anders zu laufen. Es wäre super, wenn wir rausfinden würden, was da so komisch auf Resets reagiert. Dann ist es sicher ein einfacher Fix.

Die VM neu installieren ist eine riesige Arbeit. Da ist z.B. auch noch Graphana drauf. Das läuft natürlich auch nach den Resets problemlos ;-)

Wenn dann würde ich irgendwie das backitup-Backup zurückspielen. Dazu müsste ich wohl iobroker einfach löschen, neu anlegen, backitup installieren und dann das Backup zurückspielen? Dann kommen alle Adapter, Skripte, Datenpunkte und Einstellungen wieder? Oder wie ginge das am saubersten?

So ein Ausfall ist extrem deprimierend :-( Und ich habe Angst vor der riesigen Arbeit, die da auf mich zukommen könnte. Bis alles wieder funktioniert kann es lange dauern... So viel kann ja bei der aktuellen Installation gar nicht kaputt sein, das müsste man doch reparieren können.

fastfoot

@chrisprefect ich verstehe dein Anliegen durchaus :-) Linux ist nunmal dafür bekannt dass das passieren kann, Windows ist da nicht so anfällig dafür. Mit iobroker selbst hat das nicht viel zu tun. Ich denke es hat deine objects.json und states.json verloren. Eigentlich macht iobroker immer noch ein backup dieser beiden, schau mal nach dem Zeitstempel. Sonst die jetzigen sichern(ich benenne sie einfach um) und aus backitup extrahieren(da bin ich nicht sicher ob die dort so als Datei vorliegen)

Ansonsten hatte ich an eine Kopie der jetzigen VM gedacht. Dort das backup einspielen, ohne neu aufzusetzen. Das erhält dir die alte als Notnagel

skorpil

@chrisprefect nö geht auch im eingeschalteten Zustand. Ich erstelle mir nach jeder Änderung am iobroker einen Sicherungspunkt und komme damit gut klar.

Thomas Braun

@chrisprefect

Versuchs Mal danach:

https://forum.iobroker.net/topic/43325/mini-howto-cannot-find-view-system-for-search-host

Und hampel da nicht als root rum. Macht man genauso wenig wie hartes ausschalten von Systemen.

Der Bildschirm beim Booten 'Das System wurde nicht ordnungsgemäß heruntergefahren, Windows versucht eine Wiederherstellung' (oder so ähnlich) ist vermutlich nur ein Gerücht...

ChrisPrefect

@thomas-braun DAS WARS! Das Zurückspielen der letzten states- und object-Backups hat das System wieder zum laufen gebracht!!! Genial

Danke!

Also doch kein tagelanges komplettes Neuaufsetzen des Systems. Phu...

Thomas Braun

@chrisprefect

Den Umgang mit dem System solltest du dennoch ändern.

ChrisPrefect

@thomas-braun Hmm, grundsätzlich hast du natürlich recht.

Praktisch ist es bei mir wirklich egal, ob ich root bin oder nicht. Ich würde sowieso bei 100% der Logins einfach erst mal "su" eingeben und wäre dann eh wieder root. Ich logge mich nie auf dem System ein. Ausser, ich muss etwas flicken. Und dann ist es mühsam, wenn die Hälfte der Befehle erst mal fehlschlägt, weil ich nicht sudo vorne rangestellt habe.

Wieso denkst du, ich schalte die Systeme zum Spass hart aus? Ich musste das Hauptsystem runterfahren, weil die Grafikkarte kaputt war. Ich bin davon ausgegangen, dass VirtualBox die VMs per ACPI runterfährt. Anscheinend passiert das aber nicht.

Keine der anderen VMs hat damit irgend ein Problem, aber anscheinend aktualisiert ioBroker diese Datei-Datenbanken ohne atomare Aktionen, sodass trotz journaling Filesystem, die Daten danach inkonsistent sein können. Da müsste ioBroker den Umgang mit diesen Files überdenken. Anscheinend werden die Files Stück für Stück rausgeschrieben und lange offen gehalten, statt im Speicher die Daten zu sammeln und dann in einer Schreiboperation zu speichern?

Thomas Braun

@chrisprefect
root-shell oder user-shell macht schon einen Unterschied.
Ein Debian-Linux ist mittlerweile mehr oder minder komplett darauf umgestellt.
Wenn du da jetzt mit einem root ankommst passt das nicht mehr.
Deswegen immer als user einloggen und per sudo die entsprechenden Rechte erhalten.

Vollkommen egal, ob die VM per ACPI oder irgendwas anderem heruntergefahren wird, denn der ioBroker hält seine Datenbankfiles recht lange im RAM. Das um die Zahl der Schreibvorgänge auf die oft genutzten SD-Karten bei SBCs wie dem Raspberry Pi möglichst gering zu halten.
Deswegen das System mit dem laufenden ioBroker immer möglichst geordnet herunterfahren.

iobroker stop
sudo shutdown

ChrisPrefect

@thomas-braun Das Vorgehen zum Restore der letzten objects und states sollten eigentlich hier noch verlinkt werden:

https://www.iobroker.net/docu/index-26.htm?page_id=3928&lang=de

Glasfaser

@chrisprefect sagte in ioBroker nicht erreichbar nach Neustarts. Admin.0 fehlt?:

sollten eigentlich hier noch verlinkt werden:
https://www.iobroker.net/docu/index-26.htm?page_id=3928&lang=de

Alter Link !!!!!

die DOKU hier ist aktuell :

https://www.iobroker.net/#de/documentation/trouble/RunsNoMore.md

.

Homoran

@chrisprefect sagte in ioBroker nicht erreichbar nach Neustarts. Admin.0 fehlt?:

Das Vorgehen zum Restore der letzten objects und states sollten eigentlich hier noch verlinkt werden:

diese Doku ist seit Jahren offline.
und da dies ein anscheinend temporäres Problem einzelner Installationen ist, wird es auch nicht in die neue übrenommen, bis wir wissen woran es wirklich liegt.

Bisher waren es immer unsachgemäß (durch Stecker raus, oder Stromausfall) beendete Systeme.

Die Funktion des Wiederherstellens aus diesen Backups ist im Controller implementiert und sollte automatisch funktionieren

fastfoot

@homoran sagte in ioBroker nicht erreichbar nach Neustarts. Admin.0 fehlt?:

Die Funktion des Wiederherstellens aus diesen Backups ist im Controller implementiert und sollte automatisch funktionieren

Gerade gestern hatte ich Probleme beim Anzeigen von Werten im Objektbaum und habe einfach mal den iobroker gestoppt, die objects.json und states.json umbenannt und neu gestartet. Zu meiner Verwunderung war noch alles da, allerdings dachte ich dass er sich die Daten aus den .bak gezogen hat. Wie sich das System verhält, wenn die Dateien noch da sind, aber defekt, ist schwer zu beurteilen

ChrisPrefect

@glasfaser @homoran

Der "alte" Link ist der erste, den Google anzeigt:

https://www.google.com/search?q=iobroker+läuft+nicht+mehr

Warum also nicht da auf die neue Seite verlinken oder weiterleiten? Ich hätte niemals im Forum nach einem Link zur Doku gesucht. Bisher habe ich ioBroker immer komplett neu installiert, wenn das Problem aufgetreten ist. Natürlich mit riesen Aufwand. Wenn ich diesen Link schon früher gefunden hätte, wäre mir viel Arbeit erspart geblieben.

und da dies ein anscheinend temporäres Problem einzelner Installationen ist,

Nicht wirklich. Ich bin sicher schon drei Mal in dieses Problem gelaufen. Offensichtlich schreibt ioBroker die Files nicht atomar raus und wenn er dabei irgendwie unterbrochen wird, ist die Installation danach kaputt.

Bisher waren es immer unsachgemäß (durch Stecker raus, oder Stromausfall) beendete Systeme.

Auch diese "unsachgemässen" Events sollten korrekt behandelt werden. Ich kenne sonst keine Software, die damit Probleme hätte. Seit NTFS gibt es solche Fälle nicht mehr.

Ich bin riesig froh, dass mein System wieder läuft

arnold

nach update admin 5.0.7
komme ich nicht auf die iobroke Oberfläche
über ssh
iobroker status

pi@raspberrypi4-iob:/opt/iobroker $ iobroker status
 Cannot read system.config: null (OK when migrating or restoring)
 Cannot find view "system" for search "host"
iobroker is running on this host.


Objects type: file
States  type: file

/opt/iobroker $ iobroker list instances

pi@raspberrypi4-iob:/opt/iobroker $ iobroker list instances
 Cannot read system.config: null (OK when migrating or restoring)
 Cannot find view "system" for search "host"


+ instance is alive

cd /opt/iobroker
node node_modules/iobroker.js-controller/controller.js --logs

pi@raspberrypi4-iob:/opt/iobroker $ node node_modules/iobroker.js-controller/controller.js --logs
2021-04-24 01:46:01.279  - info: host.raspberrypi4-iob iobroker.js-controller version 3.2.16 js-controller starting
2021-04-24 01:46:01.286  - info: host.raspberrypi4-iob Copyright (c) 2014-2021 bluefox, 2014 hobbyquaker
2021-04-24 01:46:01.287  - info: host.raspberrypi4-iob hostname: raspberrypi4-iob, node: v12.22.0
2021-04-24 01:46:01.287  - info: host.raspberrypi4-iob ip addresses: 192.168.178.80 2003:cc:b714:bb00:b8c4:13a4:6aa3:64ef fe80::8878:ef2f:5641:241c
2021-04-24 01:46:01.325  - info: host.raspberrypi4-iob-Server  Error inMem-objects listening on port 9001: Error: listen EADDRINUSE: address already in use 127.0.0.1:9001
2021-04-24 01:46:31.314  - error: host.raspberrypi4-iob No connection to databases possible, restart
2021-04-24 01:46:31.325  - info: host.raspberrypi4-iob iobroker _restart
2021-04-24 01:46:31.998  - info: host.raspberrypi4-iob iobroker Starting node restart.js

IST PORT 8081 NICHT ok ?

Thomas Braun

@arnold json kaputt. Such das MiniHowTo. Die Fehlermeldung hilft dabei.

Edith:
Ist oben schon verlinkt.

Community Forum

NEWS

ioBroker nicht erreichbar nach Neustarts. Admin.0 fehlt?

Support us

570

32.7k

82.6k

1.3m