Wie kann der Übertragungs-Daemon in einem Docker-Container ordnungsgemäß beendet werden?

926
lama02

Ich versuche, einen eigenständigen Übertragungs-Daemon mit https zu andocken. Also ich verwende transmission-daemonund nginxPakete und der Docker basiert auf alpine Linux.

Um beide Programme auszuführen, verwende ich supervisor.

Alles funktioniert gut, aber ich möchte, dass docker container stopmein Container graziös getötet wird. Ich habe also konfiguriert supervisor, das TERM-Signal an weiterzuleiten transmission-daemon.

Dies funktioniert gut, wenn die Übertragung im Leerlauf ist. Wenn ich den Container jedoch stoppe, wenn er etwas herunterlädt oder etwas tut, funktioniert er leider nicht. Es scheint das Signal völlig zu ignorieren, da es auch nach dem Download noch läuft.

Ich habe absolut keine Ahnung warum. Kann mir bitte jemand weiterhelfen?

Hier ist meine Supervisor-Übertragungskonfiguration:

[program:transmission] user=transmission command=/usr/bin/transmission-daemon -f stopsignal=TERM stopwaitsecs=60 stopasgroup=true killasgroup=true

Ich bin offen für jeden Vorschlag.

1

2 Antworten auf die Frage

1
Xen2050

Aus dem Transmission-Arch-Wiki sieht es so aus, als wären die folgenden Befehle zu beenden transmission-daemon:

killall transmission-daemon

Oder

$ transmission-remote --exit

Oder von Ubuntus Hilfe:

transmission-remote -n 'transmission:transmission' -q

Ich denke, ein SIGTERM- und ein TERM-Signal sind die gleichen, und killallstandardmäßig wird ein SIGTERM-Signal gesendet. Es sieht so aus, als sollte Ihr Supervisor arbeiten ... Nach dem Stopwaitsecs sollte er auch ein KILL-Signal senden, es sei denn, er sendet nicht das richtige Signale zur richtigen Zeit ... Bestätigen Sie in einem Terminal, dass TERM / SIGTERM die Übertragung abbricht. Wenn nicht, ist es vielleicht ein Fehler.

Versuchen Sie, ein Hinzufügen redirect_stderroder stdout_logfileLinie zu sehen, ob es supervisord sagen werde alles nützlich

Vielen Dank für Ihre Antwort. "transmission-remote --exit" scheint zu funktionieren. Ich habe viele Tests gemacht und das Problem ist das gleiche, wenn ich beim Herunterladen manuell ein Signal an die Übertragung sende. Es scheint es zu ignorieren. Aber ich habe den gleichen Test basierend auf dem Archlinux-Image durchgeführt und es funktioniert perfekt ... Die Übertragungsversion beider Distributionen ist gleich (2.92). Ich denke, die Ursache ist komplizierter: vielleicht ein Unterschied im Signalmanagement zwischen Alpine und Archlinux? Es liegt jenseits meiner Fähigkeiten ... lama02 vor 6 Jahren 0
Ich bin mit Alpine nicht vertraut, aber es muss der Unterschied sein, ein einfaches Signal * sollte * funktionieren. Wenn jedoch nur "transmission-remote --exit" funktioniert, könnten Sie versuchen, den Quellcode zu untersuchen, um herauszufinden, was genau "--exit" ist. Dies ist kein Skript, daher ist es nicht so einfach wie "$". `Leider, aber das würde dem Supervisor ohnehin nicht helfen, es ist so eingerichtet, dass Signale einfach verwendet werden können ... Ich neige eher zu einem Fehler in Alpines Übertragung Xen2050 vor 6 Jahren 1
"transmission-remote --exit" ruft "tr_sessionClose" auf und schließt die Übertragung sauber. Ich verstehe nicht, wie TERM- oder INT-Signale diese Funktion auch aufrufen, aber ich denke, es ist der Fall, weil ich, wenn es bei meinen Tests funktioniert, dieselben Protokolle sehen kann wie der Aufruf von 'tr_sessionClose'. Sie glauben also, es könnte ein Fehler in der alpinen Übertragung sein? Aber es gibt sowohl auf Archlinux als auch auf Alpine die gleichen Versionen. Wie ist das möglich? lama02 vor 6 Jahren 0
Ich habe bis heute noch nie von Alpine Linux gehört, aber anscheinend basiert es auf busybox & musl (C-Bibliothek) und verwendet kein glibc (das Repo von Debian nennt glibc6 "die Standardbibliotheken, die von fast allen Programmen des Systems verwendet werden") könnte etwas sein. Sie könnten versuchen, den Quellcode von arch & Alpines Paketen zu vergleichen? Oder versuchen Sie die Methode ihres Wikis: http://wiki.alpinelinux.org/wiki/Setting_up_Transmission_(bittorrent)_with_Clutch_WebUI, das sie mit HTTP steuert ("Übertragungs-Daemon wird über Clutch gesteuert, die von lighttpd betrieben wird"). Xen2050 vor 6 Jahren 1
Okay danke. Es gibt eindeutig ein Problem mit der Übertragung in Alpine Linux. Ich habe den folgenden Test für Arch und Alpine in der interaktiven Shell ausgeführt: Den Übertragungs-Daemon im Vordergrund ausführen, einen Torrent über das Web-Interface hinzufügen und das INT-Signal senden (Ctrl + C). Auf Alpine: seg Fehler oder mehrere Signale ignoriert (ich muss -9 senden, um ihn zu töten). Auf Archlinux: Es funktioniert perfekt, die Übertragung macht das Zeug und macht halt sauber. lama02 vor 6 Jahren 0
Es sieht aus wie ein Fehler und verhält sich wie ein Fehler, besonders getestet mit der gleichen Version auf einem anderen System. Ich denke, es ist ein Fehler. Das ist ein Vorteil von größeren Distributionen wie Debian (& direkt abgeleitet), mehr Testern und Augen, um Fehler zu finden. Vielen Dank für die Überprüfung, ich habe auch Ihren Fehlerbericht aktualisiert, da er definitiv eine nützliche Antwort ist. Viel Glück! Xen2050 vor 6 Jahren 1
Sicher für größere Distros, aber für Docker-Container sieht Alpine perfekt aus. Ich bin neu bei Docker und Alpine, ich habe vorher immer Archlinux verwendet. Ich hoffe also, dass jemand den Fehler behebt, sonst mache ich meine Container auf Arch-Basis. Danke für den Aufwärtspfeil und Ihre Hilfe, ich habe Sie auch aufgestockt. lama02 vor 6 Jahren 0
1
lama02

Es ist wahrscheinlich ein Fehler. In Alpine Bug-Tracker berichtet:

https://bugs.alpinelinux.org/issues/8218

Verwandte Probleme