Docker-Container vor Neustart der DS sauber beenden

[Tom80]

Hallo,

Ich habe den Fotoserver Picapport in einem Docker-Container laufen.
Wenn ich jetzt z.B. bei einem Update der DS einen Neustart machen muss, muss ich vorher dran denken den Container sauber zu beenden, sonst wird mir die Datenbank von Picapport zerschossen und ich muss diese neu aufbauen lassen, was jedesmal viel Zeit in Anspruch nimmt.

Gibt es hierfür eine Möglichkeit vor einem Neustart den Docker-Container sauber beenden zu lassen?

Tom

 

[haydibe]

Du kannst auf der Shell als root die Datei "/var/packages/Docker/scripts/start-stop-status" bearbeiten.

In den Zeilen 220ff findest Du die Aktionen zum Anhalten: "stop)".

In der Zeile dadrunter kannst Du folgenden Befehl einfügen, der alle laufenden Docker-Container beendet, bevor das Docker Paket beendet wird:

docker stop $(docker qs -q)

Du musst mal schauen, ob das Auswirkungen auf den Autostart von Containern hat (je nach dem welchen Modus Synology da setzt, hat es keine Auswirkungen oder eben doch).

 

[geimist]

... oder die Zeile über den Aufgabenplaner, ausgelöst durch Herunterfahren, ausführen lassen. Vorteil: die Änderung am Start-stop-Skrip übersteht wahrscheinlich ein Update nicht (und irgendwann vergisst man die Anpassung).

@haydibe:

In der Zeile dadrunter kannst Du folgenden Befehl einfügen, der alle laufenden Docker-Container beendet, bevor das Docker Paket beendet wird:

docker stop $(docker qs -q)

Ich gehe mal davon aus, dass du so meinst :

docker stop $(docker ps -q)

Allerdings wird bei mir (bis auf Bitwarden - steht als erstes in der Liste) ein unerwartetes Beenden der Container angemängelt.

---

@haydibe:
Der Befehl 'pause' hält den Container, ohne eine entsprechende Warnmeldung auszugeben. Wäre ein Beenden in diesem Zustand ein Risiko für die Datenkonsistenz?

 

[haydibe]

Der Shutdown-Task ist viel charmenter! Danke auch für die Korrektur vom Typo

Hmm, Container deren Prozesse mit Docker pause eingefroren wurden, haben ihren Zustand immer noch im Arbeitsspeicher.
Das kann man einsetzen, wenn ein Container gerade viel Last erzeugt und man die CPU für etwas anderes frei machen will. Einen Restart übersteht der In-Memory-State aber nicht.

Und hier haben wir auch nochmal den Weg über die Synology-Webapi:

for container in $(docker ps --format "{{ .Names }}"); do
 /usr/syno/bin/synowebapi --exec api=SYNO.Docker.Container version=1 method=stop name="$container"
done

 

[geimist]

Sehr schön - vielen Dank
Das funktioniert ohne Fehlermeldung.

Wo hast du denn die Synology-WebAPI ausgegraben?
Gibt es dazu eine Doku?

 

[haydibe]

Gerne!

Die Verwendung der Web-Api habe ich zum ersten mal im gepimpten Gitlab-Package von raffnix84 gesehen: https://github.com/jboxberger/synology-gitlab-jboxberger/blob/master/src/scripts/start-stop-statu - ohne das Skript wüsste ich auch nichts von der Web-API oder wie sie zu verwenden ist.

 

[Tom80]

Danke für die ganzen antworten!
Ich werde das mal testen und mich wieder melden.

Tom

 

[Yippie]

Mal grundsätzliche Frage dazu: bedeutet dies, dass das DSM die Docker-Instanzen nicht automatisch beendet und sauber runterfährt?

Michael

 

[haydibe]

In der Datei /var/packages/Docker/scripts/start-stop-status gibt es im stop) Block folgende Zeile:

/usr/syno/bin/synowebapi --exec api=SYNO.Docker.DDSM method=stop version=1

Wenn ich die Zeile in einer Root-Shell ausführt, erhalte ich folgendes zurück:
[Line 259] Exec WebAPI: api=SYNO.Docker.DDSM, version=1, method=stop, param={}, runner=

{
   "data" : {},
   "httpd_restart" : false,
   "success" : true
}

Danach laufen alle Container aber weiter...


Es muss aber noch irgendeinen Mechanismus geben, da bei einem Reboot des NAS keine Fehlermeldungen im Log sind und ich bisher noch keine Korrupten-Daten in den Volumes hatte.


Trotzdem wirkt das Ganze wie ein Bug. Die von mir oben angegebene Schleife sollte in ähnlicher Form im stop)-Block zu finden sein... Ist sie aber nicht.

 

[Tommi2day]

api=SYNO.Docker.DDSM

Ich würde vermuten, das er damit wirklich nur ein evtl installiertes DDSM stoppt. Für die "normalen" Container gibt es evtl. was anderes.

 

[geimist]

Das passt aber wieder nicht zu seiner Beobachtung:

… Wenn ich die Zeile in einer Root-Shell ausführt, erhalte ich folgendes zurück:
[Line 259] Exec WebAPI: api=SYNO.Docker.DDSM, version=1, method=stop, param={}, runner=

Danach laufen alle Container aber weiter...

 

[Tommi2day]

Ich meine das ist ganau das. Die normalen Container laufen weiter, weil nur der DDSM Container gestoppt würde.

 

[geimist]

Achso - jetzt sehe ich es auch. Docker DSM
Ich dachte in meiner Oberfläschlichkeit, du meinst, dass zwar das Paket Docker beendet wird, aber nicht die Container.

---

Nachtrag:
Docker DSM lässt sich damit beenden. Die Ausgabe ist:

root@DS:~# /usr/syno/bin/synowebapi --exec api=SYNO.Docker.DDSM method=stop version=1
[Line 259] Exec WebAPI:  api=SYNO.Docker.DDSM, version=1, method=stop, param={}, runner=
{
   "data" : {
      "containers" : [ "DDSM1" ]
   },
   "httpd_restart" : false,
   "success" : true
}

 

[haydibe]

Ich war unachtsam. Es ist tatsächlich so, dass nur DDSM beendet wird und nicht die normalen Container. Da ich bei mir kein DDSM laufen habe, ergibt es auch Sinn, dass bei mir Ausgabe leer war.

Was es tatsächlich tut ist DDSM beenden und danach das Docker Package "deaktivieren".
Ein explizites beenden der Container gibt es nicht!

Irgendwie gruselig. Wenn ich wetten müsste, würde ich mein Geld auf "der Docker-Daemon beendet laufende Container beim erhalten von SIGTER, bevor sich der Prozess beendet" setzen. Aber wissen tue ich es nicht.

 

[Tom80]

Hallo,

Danke für die antworten.
Leider hilft mir das nichts, da das Script im Container beim beenden nicht sauber beendet wird bringt mir das alles nichts.

Tom

 

[haydibe]

Per Default sendet Docker beim `docker stop {containerid}' an den Hauptpozess ein SIGTERM und nach ein paar Sekunden SIGKILL.
Wenn Dein Container damit nicht umgehen kann, musst Du wohl etwas am Image ändern...

Weitere Infos hier: https://medium.com/@gchudnov/trapping-signals-in-docker-containers-7a57fdda7d86

 

[geimist]

…
Leider hilft mir das nichts, da das Script im Container beim beenden nicht sauber beendet wird bringt mir das alles nichts.
…

Warum?
Der Befehl aus Beitrag #4 funktioniert bei dir nicht?
Er sollte das Gleiche bewirken, wie ein Beenden über die GUI, was ja bei dir wiederum funktioniert.

 

[Tom80]

Warum?
...wie ein Beenden über die GUI,...

Das funktioniert eben leider nicht, wenn ich das Docker-Image über die GUI beendet wird das Programm darin (Picapport) nicht sauber beendet.
Starte ich den Container erneut, gibt es jede Menge Datenbankfehler.

Ich muss hier nochmal mit dem Ersteller des Docker-Images Kontakt aufnehmen.

Gruß Tom

 

[geimist]

… Wenn ich jetzt z.B. bei einem Update der DS einen Neustart machen muss, muss ich vorher dran denken den Container sauber zu beenden, …

Und ich dachte, du machst das über die GUI von Docker. Wie beendest du ihn denn da sauber? Über eine GUI vom Container?

 

[Tom80]

Ich hatte immer das Problem dass nach einem neustart der DS der Picapport-Container nicht mehr sauber lief. Ich dachte das kommt daher dass dieser nicht sauber beendet wurde.
Das es auch nicht funktioniert wenn ich den Container in der Docker GUI beende war mir da noch nicht bewußt.
Ich habe im Moment noch keine Lösung wie die Software Picapport im Container sauber beendet bekomme.

Tom