1
I'm trying to dockerize a standalone transmission-daemon with https. So I'm using transmission-daemon and nginx packages, and the docker is based on alpine Linux.
To run both programs, I'm using supervisor.
All works good, but I want that docker container stop gracefully kill my container. So, I have configured supervisor to propagate TERM signal to transmission-daemon.
This works good when transmission is idle. But if I stop the container when it downloads or doing something, it unfortunately doesn't works. It seem completely ignore the signal, because even after the download finish, it keeps running.
I have absolutely no idea why. Can someone help me please?
Here is my supervisor transmission configuration:
[program:transmission]
user=transmission
command=/usr/bin/transmission-daemon -f
stopsignal=TERM
stopwaitsecs=60
stopasgroup=true
killasgroup=true
I'm open to any suggestion.
lama02
Posted 2017-11-30T12:03:29.450
Reputation: 31
Thanks for your response.
transmission-remote --exitseems work.I dit a lot of tests and the problem is the same if I manually send signal to transmission when it downloading. It seems ignore it.
But I did the same test based on Archlinux image and it works perfectly... transmission-version of both distribution are the same (2.92).
So I think the cause is more complicatly: maybe a difference in signal management between Alpine and Archlinux? It's beyond my skills... – lama02 – 2017-11-30T13:19:11.843
1I'm unfamiliar with Alpine, but it must be the difference, a plain signal should work. But if only
transmission-remote --exitdoes work, could try investigating it's source code to see exactly what--exitdoes, it's not a script so it's not as easy asless $(which ...)unfortunately, but then that wouldn't help supervisor anyway, it's set up to easily use signals... I'm leaning more towards bug in Alpine's transmission – Xen2050 – 2017-11-30T13:26:23.147transmission-remote --exitcallstr_sessionCloseand cleanly close transmission. I do not understand how TERM or INT signals calls this function too, but I think it's the case because when it works on my tests I can see same logs astr_sessionClosecall. So, you think it can be a bug in Alpine transmission? But there is the same versions on both Archlinux and Alpine, so how is possible? – lama02 – 2017-11-30T15:03:17.5531
I've never heard of Alpine linux before today, but apparently it's based on busybox & musl (C library), not using glibc (Debian's repo calls glibc6 "the standard libraries that are used by nearly all programs on the system") so that could be something. You could try comparing the source code from arch & Alpine's packages? Or could try their wiki's method http://wiki.alpinelinux.org/wiki/Setting_up_Transmission_(bittorrent)_with_Clutch_WebUI controlling it with HTTP ("transmission-daemon will be controlled via Clutch which is run by lighttpd")
– Xen2050 – 2017-11-30T18:31:46.807Okay, thanks. There is clearly a problem with transmission in Alpine Linux. I did the following test on Arch and Alpine in interactive shell: running transmission-daemon in foreground, adding a torrent via web interface, send INT signal (Ctrl + C). On Alpine: seg fault or multiple signals ignored (I have to send -9 to kill it). On Archlinux: it's works perfectly, transmission doing it stuff and cleany stop. – lama02 – 2017-11-30T20:12:00.500
1It looks like a bug & acts like a bug, especially tested with the same version on another system, I think it's a bug :) That's an advantage of bigger distros like Debian (& directly derived), more testers & eyes to find bugs. Thanks for the check, I up-arrowed your bug report too since it's definitely a useful answer. Good luck! – Xen2050 – 2017-12-01T10:21:00.287
Sure for bigger distros, but Alpine looks perfect for docker containers. I'm new to docker and Alpine, I always used Archlinux before. So, I hope someone fix the bug, otherwise I'll make my containers based on Arch. Thanks for up-arrow and your help, I up-arrowed you too. – lama02 – 2017-12-01T11:46:06.780