Graceful stop of the container is not handled correctly #311
Comments
|
Could you try to override |
|
I always assumed that was a docker setting, see Edit...now that I re-read the documentation. It's confusing. stop_signal says the default is SIGTERM (Nice/Graceful) and stop_grace_period says time before SIGKILL. In my experience...stop sends SIGKILL, not SIGTERM by default. |
it is the first thing I tried, it was set to true and when I set it to false it didn't work because rtorrent tries to find some terminal (if launched in foreground it is supposed that shuold be something to output) and it doesn't find it so it fills the log with errors.
rtorrent shuold receive SIGINT to gracefully stop but also SIGTERM is ok. |
|
@de666 Thanks so much for the additional information. I will make a pull request for this docker container with the environment variable you can configure to run rTorrent in the foreground. It will use a Linux screen session. |
Thanks! This tries to stop rtorrent process gracefully sending control-q to the screen session before sending the SIGTERM |
This pull requests add the `RT_DAEMON_MODE` environment variable which allows the user to configure how rTorrent is launched. rTorrent is still launched in daemon mode by default unless the user changes it. When daemon mode is disabled, rTorrent will launch in the foreground on a linux screen instead. This has some graceful exit benefits in limited circumstances. See crazy-max#311
This pull requests add the `RT_DAEMON_MODE` environment variable which allows the user to configure how rTorrent is launched. rTorrent is still launched in daemon mode by default unless the user changes it. When daemon mode is disabled, rTorrent will launch in the foreground on a linux screen instead. This has some graceful exit benefits in limited circumstances. See crazy-max#311
|
@stickz in the meanwhile I've made some other test running the container totally disabling the rtorrent service and I realize the problem it is not related to that service. It seems all the services are shutted down properly by s6 and s6-svscan knows it (if you put a finish script for each service it is correctly executed). |
|
Thanks, I will close off that PR. |
de666
changed the title
|
I will look to update to latest v3 of s6-overlay |
|
Any progress here? :) |
|
For me all services exit within 1-2 seconds on a fresh image (0 torrents). It's some socklog processes that remain active until Docker forces the container down, tested with a stop_grace_period of 20s. Before stopping the container: After about 2-3 seconds: Logs |
|
The |
@crazy-max only knows... |
|
Currently I have a script doing something like backgrounding |
Support guidelines
I've found a bug and checked that ...
Description
When stopping the container with docker compose stop, the container shuold stop gracefully but this doesn't happen.
Expected behaviour
In the doc it is reported:
Actual behaviour
Docker it waits always 10 seconds (or the number of seconds specified in stop_grace_period), not less, regardless of how many torrents are active/seeding etc.
Even with no torrents at all, docker waits always 10 seconds (or the number of seconds specified in stop_grace_period) before considering the container as stopped.
Steps to reproduce
Docker info
Docker Compose config
No response
Logs
Additional info
see #311 (comment)
The text was updated successfully, but these errors were encountered: