Docker neu starten ohne "Fehlermeldung"

[Ghost108]

Guten Morgen!

ich würde gerne meinen Docker Container "homebridge" täglich neu starten.
Dafür habe im Aufgabenplaner einen täglichen Task erstellt, mit dem Befehl:

docker restart homebridge

Das klappt auch.
Allerdings erhalte ich bei jedem Neustart von der Syno dann folgende "Fehlermeldung"



Kann ich "homebridge" auch ordnungsgemäß neu starten, damit diese Meldung nicht zustande kommt?

 

[Fusion]

Bekomme ich auch für Container die ich mit Docker-compose an der GUI vorbei betreibe.

Da mir gerade nichts besseres einfällt...

Ist der Container mit "restart always" (bei Fehlern) im Betrieb?
Vielleicht hilft es dann wenn du anstatt 'restart' auf einem Zweizeiler mit 'stop' und 'start' wechselst.

 

[Ghost108]

ist der Container mit "restart always" (bei Fehlern) im Betrieb?

ja, ist mit restart always konfiguriert

Vielleicht hilft es dann wenn du anstatt 'restart' auf einem Zweizeiler mit 'stop' und 'start' wechselst.

habe ich bereits getestet - das Ergebnis ist identisch

 

[Fusion]

Oder mal docker container restart homebridge?

 

[Ghost108]

docker container restart homebridge

-> selbes Ergebnis

Interessant wäre zu wissen, ob es eine Möglichkeit gibt, via Shell einen Restart der Homebridge auszulösen,
sowie es über das Homebridge UI funktioniert. Hier wird nur einer Restart der Homebridge Instanz ausgelöst ohne den docker neu zu starten

 

[Fusion]

Probierst mal
docker exec -it homebridge hb-service restart

https://github.com/oznu/homebridge-config-ui-x/wiki/Homebridge-Service-Command

 

[Ghost108]

docker exec -it homebridge hb-service restart
ℹ Restarting Homebridge Service
✖ ERROR: This command is not available.

 

[EDvonSchleck]

Dazu hat mit @haydibe vor einiger Zeit etwas geschrieben: (ich hoffe es ist in Ordnung, wenn ich das hier veröffentliche)

Meine Hypothese: die betroffenen Container haben einen Exit-Status-Code > 0, wenn WT den Container beendet.
Führ doch mal `docker stop` für einen der betroffenen Container durch und schau dir mit `docker ps -a` an welcher Exit-Status-Code (`Exited (x)`) in der Spalte STATUS steht. Ich gehe davon aus, dass bei allen Containern die zu der Fehlermeldung geführt haben, nicht 'Exited (0)` (=kein Fehler) steht.
Üblicherweise findet man im Container-Context die Codes 137 + 143. Hier findet man eine Erläuterung dazu: https://komodor.com/learn/sigterm-signal-15-exit-code-143-linux-graceful-termination/
Sobald ein `docker stop` ausgeführt wird, wird SIGTERM an pid1 im Container geschickt. Wenn der Prozess innerhalb einer Grace-Period von 10 Sekunden nicht beendet wird, dann wird der Container hart mit SIGKILL beendet.
Wenn SIGTERM nicht zum Beenden des Hauptprozesses führt, kann es an falschem Image-Design liegen: ENTRYPOINT/CMD im Dockerfile nutzen nicht die Array-Syntax und/oder das Entrypoint-Skript startet die Hauptanwendung nicht mit `exec`, um PID1 an diesen Prozess zu übergeben (andernfalls erreicht das SIGTERM den Hauptprozess nie!).
Es kann aber auch sein, dass das Image Design korrekt ist, aber die Hauptanwendung einfach keinen SIGTERM-Handler implementiert hat, der das Signal sauber verarbeiten würde um den Prozess geordnet zu beenden. So ist es zum Beispiel mit meinem Language-Tool Image gewesen, weswegen ich seit 5.9-8 unter Verwendung von `tini` den Exist-Status-Code schlucke.

Ich hätte vielleicht besser schreiben sollen: "Wenn es nicht richtig läuft, findet man überlicherweise..."

Der Standard sollte natürlich 0 sein.

Bei Watchtower gibt es die Überlegung den Neustart über die API zu machen, damit das System dieses besser erkennt.

 

[Ghost108]

Verstehe!
Okay, dann programmiere ich eine Lösung via Homebridge UI API

 

[Ghost108]

Update: Mit der API klappt es tadellos ohne "Fehlermeldung"
Danke für den Hinweis!!

 

[Fusion]

https://gist.github.com/mbierman/dd45821b53d5d22147cef217f0c0fe95

Code 143 kommt beim stoppen.

Trotzdem müsste man ja den Service innerhalb des Containers neu starten können, wenn es da in der GUI einen Knopf gibt.
Aber gut, möglich, dass das nur via API Call geht dann. mmmh.

Und wie sieht deine Lösung jetzt aus?

 

[DrDeath]

wahrscheinlich über zwei cURL Aufrufe an die API:

curl -X 'POST' \
  'http://<IP>:<PORT>/api/auth/login' \
  -H 'accept: */*' \
  -H 'Content-Type: application/json' \
  -d '{
  "username": "dein-hb-username",
  "password": "dein-hb-password",
  "otp": "string"
}'

Response Body: z.b.

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InN0ZW1hdGgiLCJuYW1lIjoic3RlbWF0aCIsImFkbWluIjp0cnVlLCJpbnN0YW5jZUlkIjoiYTE1MzVjYWZmNDQ2MGQxODA0M2I5NWExOGU5N2RkY2Q4NGFlYjU5Y2VkNTY3NzNjMDUwY2QzNTdiOWRiNDgwNCIsImlhdCI6MTY3NTcxMzA5MCwiZXhwIjoxNjc1NzQxODkwfQ.dvC4ByR-6yx0uZixpDnJGpTg7Cz3xcuE2nn_Dv3nD-o",
  "token_type": "Bearer",
  "expires_in": 28800
}

Vom Response Body den "access_token" auslesen und an den nächsten cURL einbauen:

curl -X 'PUT' \
  'http://<IP>:<PORT>/api/server/restart' \
  -H 'accept: */*' \
  -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InN0ZW1hdGgiLCJuYW1lIjoic3RlbWF0aCIsImFkbWluIjp0cnVlLCJpbnN0YW5jZUlkIjoiYTE1MzVjYWZmNDQ2MGQxODA0M2I5NWExOGU5N2RkY2Q4NGFlYjU5Y2VkNTY3NzNjMDUwY2QzNTdiOWRiNDgwNCIsImlhdCI6MTY3NTcxMzA5MCwiZXhwIjoxNjc1NzQxODkwfQ.dvC4ByR-6yx0uZixpDnJGpTg7Cz3xcuE2nn_Dv3nD-o'

Response Body:

{
  "ok": true,
  "command": "SIGTERM",
  "restartingUI": false
}

 

[Ghost108]

Korrekt. Via PHP gelöst