Meine Gladys-Instanz war heute Morgen ausgefallen.
Der Gladys-Container läuft zwar, reagiert aber nicht auf Port 80.
Alle anderen Container auf meinem Mini-PC funktionieren (node-red, z2m…)
In den Gladys-Logs habe ich einige Fehler, die relativ häufig auftreten: sudo docker logs Gladys
Ich habe das Gefühl, dass das Problem seit einem von Watchtower ausgelösten Update besteht
sudo docker ps :
« 23 hours ago » entspricht genau dem Zeitpunkt, an dem ich keine Telegram-Benachrichtigungen von Gladys mehr erhalten habe.
Was habe ich kürzlich an Gladys geändert?
→ Ich habe eine Szene mit einer Aktion ‹ Warten › von 24 Stunden konfiguriert (ich bezweifle, dass das der Grund ist)
Ich habe natürlich versucht, den Gladys-Container neu zu starten und einen vollständigen Neustart des Geräts durchgeführt, aber das Problem besteht weiterhin. Gladys ist von anderen Geräten aus nicht erreichbar.
Ich kann bei Bedarf weitere Logs teilen.
Haben Sie andere Debugging-Tipps? Bin ich der Einzige, der dieses Verhalten seit einem Update hat?
Das Update von Montag war wirklich nur eine kleine Sache, auf der Backend-Seite hat sich quasi nichts geändert… Also wäre ich sehr überrascht, wenn das Update selbst der Grund wäre.
Einige Routineüberprüfungen:
Gibt es noch genug freien Speicherplatz auf deinem Mini-PC? df -h um das in der CLI zu überprüfen
Ist der Mini-PC aus irgendeinem Grund überlastet? htop ist praktisch, um das zu überprüfen
Ja, ich habe den Speicherplatz überprüft: kein Problem, es ist noch genug Platz vorhanden.
Und htop sieht auch gut aus, mein System ist nicht überlastet.
Ich sende die vollständigen Logs so schnell wie möglich.
2024-04-09T04:50:48+0200 index.js:15 (process.) unhandledRejection catched: Promise {
TypeError: Ungültiger Wert « undefined » für den Header « authorization »
at ClientRequest.setHeader (node:_http_outgoing:651:3)
at new ClientRequest (node:_http_client:291:14)
at Object.request (node:https:366:10)
at RedirectableRequest._performRequest (/src/server/node_modules/follow-redirects/index.js:284:24)
at new RedirectableRequest (/src/server/node_modules/follow-redirects/index.js:66:8)
at Object.request (/src/server/node_modules/follow-redirects/index.js:523:14)
at dispatchHttpRequest (/src/server/node_modules/@gladysassistant/gladys-gateway-js/node_modules/axios/lib/adapters/http.js:202:25)
at new Promise ()
at httpAdapter (/src/server/node_modules/@gladysassistant/gladys-gateway-js/node_modules/axios/lib/adapters/http.js:46:10)
at dispatchRequest (/src/server/node_modules/@gladysassistant/gladys-gateway-js/node_modules/axios/lib/core/dispatchRequest.js:53:10)
at Axios.request (/src/server/node_modules/@gladysassistant/gladys-gateway-js/node_modules/axios/lib/core/Axios.js:108:15)
at Axios. [as get] (/src/server/node_modules/@gladysassistant/gladys-gateway-js/node_modules/axios/lib/core/Axios.js:129:17)
at Function.wrap [as get] (/src/server/node_modules/@gladysassistant/gladys-gateway-js/node_modules/axios/lib/helpers/bind.js:9:15)
at Object.get (/src/server/node_modules/@gladysassistant/gladys-gateway-js/lib/request.js:86:6)
at GladysGatewayJs.enedisGetDailyConsumption (/src/server/node_modules/@gladysassistant/gladys-gateway-js/index.js:1177:23)
at Gateway.enedisGetDailyConsumption (/src/server/lib/gateway/enedis/gateway.enedisGetDailyConsumption.js:17:56)
at recursiveBatchCall (/src/server/services/enedis/lib/enedis.sync.js:24:37)
at /src/server/services/enedis/lib/enedis.sync.js:92:32
at tryCatcher (/src/server/services/enedis/node_modules/bluebird/js/release/util.js:16:23)
at Object.gotValue (/src/server/services/enedis/node_modules/bluebird/js/release/reduce.js:166:18)
at Object.gotAccum (/src/server/services/enedis/node_modules/bluebird/js/release/reduce.js:155:25)
at Object.tryCatcher (/src/server/services/enedis/node_modules/bluebird/js/release/util.js:16:23)
at Promise._settlePromiseFromHandler (/src/server/services/enedis/node_modules/bluebird/js/release/promise.js:547:31)
at Promise._settlePromise (/src/server/services/enedis/node_modules/bluebird/js/release/promise.js:604:18)
at Promise._settlePromiseCtx (/src/server/services/enedis/node_modules/bluebird/js/release/promise.js:641:10)
at _drainQueueStep (/src/server/services/enedis/node_modules/bluebird/js/release/async.js:97:12)
at _drainQueue (/src/server/services/enedis/node_modules/bluebird/js/release/async.js:86:9)
at Async._drainQueues (/src/server/services/enedis/node_modules/bluebird/js/release/async.js:102:5)
at Immediate.Async.drainQueues (/src/server/services/enedis/node_modules/bluebird/js/release/async.js:15:14)
at processImmediate (node:internal/timers:476:21) {
code: ‹ ERR_HTTP_INVALID_HEADER_VALUE ›
}
Ich weiß nicht, ob das mit meinem Absturz zusammenhängt, aber ich versuche, Informationen zu finden.
Beim Neustart des gladys-Containers fallen mir diese Logs auf:
2024-04-10T20:40:42+0200 index.js:15 (process.) unhandledRejection catched: Promise {
TypeError: Cannot read properties of undefined (reading ‹ substr ›)
at /src/server/lib/scene/scene.addScene.js:45:47
at Array.forEach ()
at SceneManager.addScene (/src/server/lib/scene/scene.addScene.js:36:20)
at /src/server/lib/scene/scene.init.js:22:10
at Array.map ()
at SceneManager.init (/src/server/lib/scene/scene.init.js:20:30)
at Object.start (/src/server/lib/index.js:150:9)
at /src/server/index.js:51:3
}
2024-04-10T20:40:42+0200 index.js:16 (process.) TypeError: Cannot read properties of undefined (reading ‹ substr ›)
at /src/server/lib/scene/scene.addScene.js:45:47
at Array.forEach ()
at SceneManager.addScene (/src/server/lib/scene/scene.addScene.js:36:20)
at /src/server/lib/scene/scene.init.js:22:10
at Array.map ()
at SceneManager.init (/src/server/lib/scene/scene.init.js:20:30)
at Object.start (/src/server/lib/index.js:150:9)
at /src/server/index.js:51:3
Ich bezweifle, dass dies mit einer Szene zusammenhängt, die ich kürzlich mit einer « Wait »-Aktion von 24 Stunden erstellt habe. Hätten wir dann nicht mehr Logs, oder?
Tatsächlich kam das von einer jeden Monat geplanten Szene ohne Uhrzeit (mein Fehler).
Ich habe die Szene in der Datenbank gelöscht und meine Instanz funktioniert jetzt richtig, danke
Infos zum Bug für ein Update:
Wir erhalten eine Fehlermeldung, wenn ein Backup mit einem monatlichen Trigger ohne Uhrzeit erstellt wird: « Ein Fehler ist beim Speichern Ihrer Szene aufgetreten. Bitte überprüfen Sie, ob alle Aktionen / Auslöser ausgefüllt und korrekt sind. » Aber die Szene wird trotzdem gespeichert und man kann die Seitenbearbeitung der Szene ohne Probleme verlassen.
Der Absturz der Instanz erfolgt, wenn die Szene im geplanten Modus gestartet wird.
Man könnte eine Standardzeit festlegen, wenn keine angegeben ist (z. B. 00:00 Uhr)
Oder den Austritt aus der Szenenbearbeitung blockieren, wenn ein Fehler vorliegt, aber das scheint mir etwas komplexer umzusetzen.
Mögliche Lösung: Szenen, die Fehler aufweisen, können gespeichert werden, aber sie dürfen nicht aktiviert werden.
=> Fehlermeldung beim Speichern und bei jedem Aktivierungsversuch über den Cursor (also im Dashboard, in der Szenenansicht und in der Szenenbearbeitungsansicht)
Begründung: Es kann sinnvoll sein, eine Szene vorzubereiten