Kann Docker Container nicht löschen

[CptGambit]

Hallo

ich hab gerade ein Problem, das ich so noch nicht hatte und krieg es nicht gelöst.
Ich hab den docker container plexinc-pms-docker und kann den weder Löschen noch Zurücksetzen oder Starten.

Beim löschen oder zurücksetzen via docker GUI über die DSM Oberfläche bekomme ich:




Ich habs schon mit Portainer versucht, aber der läuft auch in einen Fehler und wenn ich per SSH und "sudo docker rm -f 41400f63081b" kommt:
"Error response from daemon: removal of container 41400f63081b is already in progress"

Wenn ich mit docker ps- a nach dem container schaue steht da: Removal In Progress
Es wird aber nichts removed.

Außerdem hab ich das docker Paket schon mehrfach gestoppt und wieder gestartet. Leider steht der plex container auf Autostart, so dass er jedesmal wieder mitgestartet wird und ich dann vor dem gleichen Problem stehe.

Welche Möglichkeiten hat man denn noch?

 

[plang.pl]

DS mal neu gestartet?
Welche DS ist es überhaupt? Und DSM7?

 

[EDvonSchleck]

Du kannst jederzeit auch Docker komplett löschen. Ich würde aber auch erst einen Neustart der DS machen. Kannst du danach den Container stoppen?

 

[CptGambit]

DS720+ mit DSM 7.1.x

Fehler beim Eingrenzen verschwunden.
Übers Mittagessen war das Löschen des Containers wohl doch erfolgreich. Ich war vermutlich nur zu ungeduldig. Kann ja auch keiner ahnen, dass das > 15min dauert.
Aber ich hab immerhin etwas über docker Befehle gelernt

danke für die Antwort plang.pl

 

[haydibe]

Das ist aber mehr als ungewöhnlich: normalerweise haben Container eine "grace period" von 10 Sekunden zu stoppen, danach werden sie einfach hart gekillt. Außer natürlich `stop_grace_period` wurde von dir mit einer längeren Zeit konfiguriert (wie man es bspw. bei Datenbanken gerne tut). Im Image selbst kann das nicht festgelegt werden, sprich es kann also nicht das Default verhalten sein.

​

 

[CptGambit]

Hmm, nee. Also aktiv hab ich das nicht getan. Ich wüßte auch gar nicht wie. Aber wie wird denn nach dieser `stop_grace_period` gekillt?
..weil 'docker rm -f' hatte ich auch gemacht, hat aber wie gesagt nicht funktioniert (bzw hat es sehr lang gedauert).

 

[haydibe]

kill -9 {prozessid} <-- quasi: lass alles stehen und liegen und hör sofort auf zu arbeiten.

Härter geht's eigentlich nicht ^^

 

[CptGambit]

Das kenn ich natürlich, aber kann ich damit denn einen Container killen? Ich meine, da hab ich ja nicht mal ne richtige PID.

 

[haydibe]

Du nicht. Docker tut genau das jedes Mal: es sendet erst das Signal SIGTERM an den Container (=isolierten Prozess) zum Stoppen, und nach der Grace Period eben SIGKILL.
Wenn ich mich recht erinnere, ist docker rm -f auch nur docker stop && docker rm für faule

Keine Ahnung warum es bei dir hing bzw. nicht hingehauen hat. Ich hab das Verhalten in den letzten 9 Jahren mit Docker noch nicht gewesen.

Hier würde nur noch Helfen in die Logs der Docker Engine zu schauen, aber seit DSM7 hab ich keine Ahnung wie man da rankommt. Unter DSM6.2.x gab es die noch im Verzeichnis /var/log/Docker/ unter DSM7.x nicht mehr. Normalerweise kann man auf Systemen mit Systemd die Logs mit sudo journalctl -xu docker.service einsehen. Geht auf der Syno natürlich auch nicht. Ich hab bisher nicht rausgefunden, welchen Namen Synology dem Service verpasst hat.

Ohne Blick in die Logs kann man nur raten, was passiert sein könnte. Gab es zufälligerweise ein Volume Mapping auf eine USB-Festplatte, die dann innerhalb des Containers nicht mehr richtig erkannt wurde? Oder irgendwelche Netzlaufwerke die kurz weg waren. Irgendwas in die Richtung könnte ich mir vorstellen, aber wie geschrieben: man kann ohne Logs nur raten.

Update: es scheint sudo journalctl -xu pkg-Docker-dockerd.servicezu sein.

 

[Assurbanipal]

Ich habe das gleiche Problem mit der gleichen Fehlermeldung. Kann also nicht so selten sein. Gibt es schon eine Lösung?

 

[alexhell]

Siehe Beitrag #7

 

[Assurbanipal]

Sagt mir leider nichts. Wo muss ich den Befehl eingeben?

 

[alexhell]

Du musst dich per SSH verbinden. Aber wenn dir das so nichts sagt, dann wäre ich da eher vorsichtig. Hast du mal probiert die DS neu zu starten und ihn dann zu löschen?

 

[Assurbanipal]

Ich habe das Problem nach wie vor. Ein Telegraf-Container wird immer neu gestartet und vom System automatisch beendet. Löschen und Bearbeiten ist nicht möglich. Ich kann mich per ssh verbinden, bin aber absoluter Linux-Legasteniker.

Synology: DS 920+
DSM: 7.2

Kann jemand helfen?

 

[alidong]

Hallo, ich hab im Coontainer Manager das selbe Problem mit dem Grafana Container. Dieser stürzt beim Boot ab und startet immer wieder neu. Ich kann ihn weder zurücksetzten noch löschen. Über eure Hilfe wäre ich sehr dankbar.

DSM 7.2-64570 Update 1, DS1821+

 

[alexhell]

Container Logs? Es muss ja einen Grund geben. Ansonsten übers Terminal probieren.

sudo docker stop <container>

 

[haydibe]

Wenn das alles nicht zum Erfolg führt, versucht doch mal die Restart Policy des entsprechenden Containers zu beenden:

sudo docker container update --restart no ${container name oder id}

Danach sollte der Container, wenn beendet wird auch gestoppt bleiben.

Update: wenn man sich docker container update --help anschaut, dann können Dinge getan werden, die NICHT Docker Standard sind: ports publised, environments und volumes hinzufügen. Bei "vanilla Docker" können nur Ressource-Einstellungen und die Restart-Policy bei einem bestehenden Container aktualisiert werden. Entweder hat Synology das nicht an das Upstream Docker Projekt "zurückspendet", oder Docker hat es im Upstream nicht akzeptiert...

 

[alidong]

Diese Fehlermeldungen kommen im Minutentakt. Vielen Dank

2023/10/15 10:46:13	stdout	mkdir: can't create directory '/var/lib/grafana/plugins': Permission denied
2023/10/15 10:46:13	stdout	You may have issues with file permissions, more information here: http://docs.grafana.org/installation/docker/#migrate-to-v51-or-later
2023/10/15 10:46:13	stdout	GF_PATHS_DATA='/var/lib/grafana' is not writable.

 

[haydibe]

Hast Du es schon mal mit der Forensuche probiert? Das Thema "Berechtigungsprobleme bei Volumes" wurde hier schon so oft behandelt, dass es mich wundern würde, wenn keine Treffer zu dem Thema gekommen wären.

 

[alexhell]

Genau. Steht ja direkt da. Permission denied. Also musst du einen User angeben, der auch auf den Ordner zugreifen kann