"admin.0 Restart loop detected" und keine Trigger mehr

KlausStoertebeker

@thomas-braun
Ich habe eben mal über mein Smartphone geschaut, wie weit sich die Adapterversionen im stable vom latest unterscheiden. Und das ist bei einigen Adaptern schon ein ganzes Major-Release :-(
Ich glaube, dass muss ich mal mit einer Neuinstallation auf einem anderen Raspberry probieren...
Was mich nur wundert ist, dass der Fehler oben aufgetreten ist, ohne dass ich vorher irgendwas aktualisiert habe. Das habe ich erst im Nachhinein gemacht in der Hoffnung, dass sich der Fehler dadurch "rausupdated"...

mcm1957

@klausstoertebeker said in "admin.0 Restart loop detected" und keine Trigger mehr:

ich habe das "latest" Repository in Nutzung, weil ich von dort ein paar Adapter installiert habe, die ich bis dato nicht im "stable" hatte, zumindest nicht in einer Version, die alle Funktionen unterstützt haben, die ich brauchte (zum Beispiel den "zwave2.0" oder den "homepilot20.0").

Wenn ein Adapter bzw. eine Release nicht im STABLE Repository aufscheint, dann ist diese entweder bekanntermaßen fehlerhaft, brand-neu und noch im Test oder der Dev hat schlicht und einfach vergessen die Release zu aktualisieren. In letzterem Fall bitte ein Issue zur Erinnerung bzw. zur Abklrung der Ursache im Adapterrepository erstellen.

EDIT:
Mit ws aus dem Latest würde ich derzeit auch vorsichtig sein wenn du nicht testen willst.
Die 3.x.x ist ein REWRITE in Typescript und da kommen fast täglich neue Versionen raus.

Und noch was:
Entweder hab ich es hier übersehen oder es fehlt noch:
Welche Meldungen gibt den ADMIN aus bevor er crashed?

KlausStoertebeker

@mcm1957
Danke für die Info. Jetzt wird ein Schuh draus, dass der ws-Adapter sich so oft updaten wollte...
Würde ein log helfen, um zu schauen, was der admin-Adapter vor einem Absturz meldet? Ich habe die Instanz auf "debug" eingestellt und lasse die Log-Einträge über den Adapter logParser laufen. Dann gibt's das als JSON-formatierten Text...

mcm1957

@klausstoertebeker

a) Natürlich hilft ein Log in dem sthet warum admin Abstürzt um irgendwie zu evaulieren warum admin abstürzt :-). Aber bitte zeig das ganz normale log ohne zwischengeschaltete Software irgendwelcher Art - also das was du unter logs siehst. Ganz normaler Text ist naturgemäß am besten zu lesen.

Und mm besten gar NICHTs editieren - ausgenommen allfällige sensitive Daten wie Passwörter oder Zugriffstoken. (Wenn die ein Adapter logged, dann auch ruhig ein Issue beim Adapter aufmachen - best praxis wäre die gar nicht zu loggen)

b) Generell solltest du das BETA (LATEST) Repository NICHT für produktive Systeme verwenden. Auch admin

Edit:
Bezüglich DOWNGRADEs
Wenn du im Admin eine niedrigere Version als verfügbar siehst, dann sollte die auch bei einem "Update" installiert werden. Eine explizite Installation via Versionsangabe sollte nach meiner Kenntnis nicht nochtwendig sein. ABER downgrades über Major Grenzen sind auch nicht wirklich ohne. Adapter konvertieren ggF bei einem Major Upgrade Dinge. Bei einem Major Downgrade unterstützt m.W. nach kein Adapter eine Konvertierung. Persönlich würd ich major Downgrades niht global machen sondern sehr genau schaun was da denn geändert wurde und diese ggF. auch nicht machen. Aber leider kann man da nichts generell anwendbares sagen.

So und nun bitte mal um das Log des Admin :-)

Thomas Braun

@mcm1957 sagte in "admin.0 Restart loop detected" und keine Trigger mehr:

Wenn du im Admin eine niedrigere Version als verfügbar siehst, dann sollte die auch bei einem "Update" installiert werden. Eine explizite Installation via Versionsangabe sollte nach meiner Kenntnis nicht nochtwendig sein.

Nein, eine niedrigere Versionsnummer musst du immer ausdrücklich angeben. Egal aus welchem Repo die stammt. npm kennt keine Gewichtung nach Quelle, anders als z. B. apt. Da kann man das Repo bevorzugen. Tun wir (ich) z. B. bei der nodesource-Quelle für das nodejs-Paket.

mcm1957

@thomas-braun

Wo du recht hast hast du recht.

Sorry

Ich erstell dazu aber mal ein Issue ...

KlausStoertebeker

@mcm1957
Moin mcm1957,
zu dem Log eine kurze Frage:
Natürlich kann ich das herunterladen und als Textdatei zur Verfügung stellen. Aber das ist ziemlich groß, vor allem, wenn der admin-Adapter mit debug-Loglevel läuft. Ich kann das Log im ioBroker ja nach den Quellen filtern, aber wie sichere ich dann dieses gefilterte Log? Wenn ich auf Herunterladen klicke, wird trotz Filter immer das ganze Log exportiert...

Thomas Braun

@klausstoertebeker

The mighty Kommandozeile...

iob logs admin > gefiltertes.log

KlausStoertebeker

Ich habe ioBroker mittlerweile gelöscht und neu installiert - Gott sei Dank hatte ich valide Backups, so dass das relativ schnell von der Hand ging.
Der Plan dabei war, dass ich alle Adapter, die im stable-Repository vorhanden sind, auch von dort installiere. Allerdings habe ich nicht bedacht, dass nach dem Wiederhestellen des Backups ALLE Einstellungen wiederhergestellt wurden und daher auch das latest-Repository wieder eingestellt wurde.
nachdem ich das geändert hatte, habe ich dann alle Adapter manuell auf die aktuelle stable-Version aktualisiert. Und dabei bin ich auf folgende Herausforderung gestoßen:
In diesem Forenbeitrag wird verkündet, dass der js-controller jetzt in der Version 7 im stable-Repository bereitgestellt wird. Wenn ich jedoch den Befehl

iobroker update

bei aktiviertem stable-Repository ausführe, wird dort als verfügbare Version 4.0.24 angezeigt.
Ebenso verhält es sich mir dem admin-Adapter, der ja offenbar eine Major-Version von 7 haben muss, um mit dem js-controller zusammenarbeiten zu können.
Installiert bei mir ist die Version 7.4.21, als verfügbare Version wird mir jedoch 6.3.5 angezeigt. Ich habe versucht, die Version 6.3.5 zu installieren, was jedoch dazu führte, dass ich nicht auf die Admin-Oberfläche zugreifen konnte. Daher habe ich nach dem Aktivieren des latest-Repository wieder auf die Version 7.4.21 aktualisiert und das Repository wieder umgestellt (wie Thomas Braun empfohlen hat).
Kann es sich um einen Fehler im stable-Repository handeln?
Ansonsten habe ich immer noch keine Trigger (weder ereignis- noch zeitgesteuerte), so dass sich das mit der Hausautomatisierung in überschaubaren Grenzen hält :-(
Auch scheint die admin.0-Instanz nicht abzustürzen, sondern das Problem scheint bei der socketio.0-Instanz zu liegen. Denn im Log des admin-Adapters wird gemeldet, dass die socketio.0-Instanz die Verbindung zu mir als externem Nutzer unterbricht und dann wiederherstellt.

Thomas Braun

@klausstoertebeker

Ich hab keinen Überblick was da nun wie eingestellt ist.
Gib mal die Langfassung von

iob diag

zum Besten.

mcm1957

@klausstoertebeker
Ich vermute mal dass du nach dem Umstellen des Repos nicht auf "Nach Updates suchen" geklickt hast. Damit enthält das Repo alte Daten.

https://github.com/ioBroker/ioBroker.admin/issues/2420

Thomas Braun

@mcm1957

Oder zwei (oder mehrere) Repos aktiv. Da kommt es auch zu solch komischen Versionsvorschlägen.

KlausStoertebeker

@thomas-braun
Bei mir nicht, ich habe es kontrolliert - mehrfach :-)
Und das Egebnis vom iob diag kommt, wenn ich wieder zu Hause bin...

crunchip

@klausstoertebeker sagte in "admin.0 Restart loop detected" und keine Trigger mehr:

Bei mir nicht, ich habe es kontrolliert - mehrfach

bei dir steht

http://download.iobroker.net/sources-dist-stable.json

ist doch eigentlich falsch, bzw nicht erreichbar
der Eintrag sollte eigentlich so lauten

https://repo.iobroker.live/sources-dist.json

mcm1957

@crunchip
Eigentlich sollten BEIDE Einträge ok sein. Der eine wird mittesl redirect auf den anderen umgeleitet.

EDIT: sind sie aber nicht - ich frag mal nach...

EDIT #2:
Die domain ist egal, es gehen beide. ABER der Name lautet richtig sources-dist.json - also nix mit -stable hinten dran. Egal bei welcher Domain.

Außerdem ist BETA und LATEST einer zuviel.

Klick mal auf "REstore repositories to default" links oben:

Thomas Braun

echad@chet:~ $ iob repo list
┌─────────┬───────────────┬─────────────────────────────────────────────────────────┬──────────────┐
│ (index) │ name          │ url
    │ auto upgrade │
├─────────┼───────────────┼─────────────────────────────────────────────────────────┼──────────────┤
│ 0       │ 'beta'        │ 'http://download.iobroker.net/sources-dist-latest.json' │ false        │
│ 1       │ 'live-stable' │ 'http://iobroker.live/repo/sources-dist.json'   │ false        │
│ 2       │ 'live-beta'   │ 'http://iobroker.live/repo/sources-dist-latest.json'    │ false        │
│ 3       │ 'stable'      │ 'http://download.iobroker.net/sources-dist.json'│ false        │
└─────────┴───────────────┴─────────────────────────────────────────────────────────┴──────────────┘
Active repo(s): beta
Upgrade policy: none
echad@chet:~ $

Das sind die vier mir bekannten Repos.

ticaki

@thomas-braun
Weißt du worin sich live und nicht live unterscheiden?

mcm1957

@ticaki
Nur in der URL. Die .net macht nur einen redirekt auf die .live.

Ist soweit ich weiß historisch bedingt.

Thomas Braun

@ticaki sagte in "admin.0 Restart loop detected" und keine Trigger mehr:

Weißt du worin sich live und nicht live unterscheiden?

'Früher'(tm) hat die eine mal besser als die andere funktioniert... :-)

crunchip

@mcm1957 sagte in "admin.0 Restart loop detected" und keine Trigger mehr:

also nix mit -stable hinten dran

das meine ich ja

@ticaki sagte in "admin.0 Restart loop detected" und keine Trigger mehr:

worin sich live und nicht live unterscheiden

es gab vor rund 2 bis 3 Jahren vereinzelt bei dem ein oder anderen einen bug und funktionierte nur noch die .live/repo

Community Forum

NEWS

"admin.0 Restart loop detected" und keine Trigger mehr

Support us

568

32.5k

81.9k

1.3m