Can't exit transmission cleanly when using custom RPC settings

[gxfxyz]

I noticed my transmission won't save setting changes made via the GUI to the settings.json file when stopping the container.

After some digging, I found out it's because I have some custom RPC settings in my settings.json.

This container uses /usr/bin/transmission-remote --exit command to exit transmission cleanly via RPC protocol. But it won't work if the default related RPC settings have changed.

1. Change rpc-port from 9091 to something else:

2. Enable rpc-authentication-required:

Have to disable rpc-authentication-required to make it work:

[aptalca]

1. There shouldn't be any need to change the rpc port inside the container. You can always map it in your docker create or compose yaml
2. For some reason, the alpine version of the transmission daemon does not stop when it receives a SIGTERM if it has active torrents. The only way we can stop it is via the remote call. Unfortunately if the user set a user/pass, our remote call fails (thanks for bringing it to our attention).

I'll get a PR in that will let the user define the user/pass as environment variables when creating the container, so that if they are set, the stop script can use an authorized call

[gxfxyz]

Hello @aptalca, thank you for this quick fix!

I have tried the new user/pass environment variables and can confirm the exit remote call is working now. However, I found the transmission daemon still can't exit nicely and save changes to the settings.json file when stopping the container.

This is probably because the container kill itself too quickly after sending the exit command to the transmission daemon. When the daemon received the exit call, it still needs some time to do some cleanup jobs including saving the settings.json file. But the container kills all processes right after telling the daemon to exit, leaving it no time to do those things.

Below are the logs when stopping the container:

After I manually added some seconds of sleep after the exit command, the transmission daemon finally can close properly:

[queeup]

Any news about this issue?

[aptalca]

Apologies for not responding earlier. Can you guys try to set this environment variable when you recreate the container and see if it helps?
S6_KILL_GRACETIME=10000, which will set the kill timeout to 10 seconds for the container (you can try a larger value if necessary).

The issue is that by default, s6 sends the SIGTERM to all leftover processes and then waits 3 seconds before sending everything a SIGKILL. This variable allows you to define a longer timeout delay.

[mgilbey]

I'm experiencing the same issue of settings.json not being saved when modified through the web interface, even with S6_KILL_GRACETIME set to 10000 as an environment variable.

It does take longer to shut down the container, and portainer gives this as the final output:

Caught SIGTERM signal!
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
localhost:9091/transmission/rpc/ responded: "success"
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.

The diagnosis of the save on shutdown being the issue seems accurate, since other modifications to settings.json do persist when the container is started and stopped.

[nemchik]

Has anyone tried setting S6_KILL_GRACETIME to something longer? Maybe 30000? Just to test and see if this resolves the issue.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mgilbey]

Setting S6_KILL_GRACETIME to 30000 or 60000 does not resolve the issue for me. Setting to 60000 doesn't cause the container to take 60s to shut down either I'd note.

The following docker compose will reproduce the problem:

  testtransmission:
    container_name: "testtransmission"
    image: "linuxserver/transmission"
    environment:
      - "USER=test"
      - "PASS=test"
      - "S6_KILL_GRACETIME=60000"
    ports:
      - "9093:9091"
    volumes:
      - "/docker/transmission/downloads:/downloads"
      - "/docker/transmission/config:/config"
      - "/docker/transmission/watch:/watch"

If you have never defined the user or pass, then this allows the settings to be saved on shut down. If you set them, this problem occurs. If you clear the user and pass environment variables, they persist, as does this issue.

For some reason, the alpine version of the transmission daemon does not stop when it receives a SIGTERM if it has active torrents. The only way we can stop it is via the remote call. Unfortunately if the user set a user/pass, our remote call fails (thanks for bringing it to our attention).

I have a simple dockerfile that does not experience this problem:

FROM alpine:latest
RUN apk add --no-cache tini transmission-daemon
VOLUME ["/watch", "/config", "/downloads", "/incomplete"]
ENTRYPOINT ["/sbin/tini", "--", "/usr/bin/transmission-daemon", "--foreground", \
  "--config-dir", "/config", \
  "--download-dir", "/downloads", \
  "--incomplete-dir", "/incomplete", \
  "--watch-dir", "/watch"]

By passing --auth --username test --password test as the docker command, it can be run with a password, will save settings on shut down, and stops with active torrents. Just noting this in case the RPC call is unnecessary complexity contributing to the problem.

[0b100100]

A higher value for S6_KILL_GRACETIME doesn't work as stated by others.

What terminates the transmission-daemon is probably the 'TERM signal' issued by the S6 supervisor logged as [s6-finish] sending all processes the TERM signal.
This happens too soon after issuing the command transmission-remote --exit resulting in losing settings done on the Web-Interface!

The results I get are the same as commented by mgilbey
With the small delay posted by gxfxyz, the 'TERM Signal' by S6 arrives much later which gives the transmission-daemon time to properly save the settings.json file, stats.json file and all resume files.

Without depending on sleep the following change in '/root/etc/services.d/transmission/run' works great for me:

#!/usr/bin/with-contenv bash

_term() {
  echo "Caught SIGTERM signal!"
  echo "Tell the transmission session to shut down."
  pid=$(pidof transmission-daemon)
  if [ ! -z "$USER" ] && [ ! -z "$PASS" ]; then
    /usr/bin/transmission-remote -n "$USER":"$PASS" --exit
  else
    /usr/bin/transmission-remote --exit
  fi
  tail --pid=${pid} -f /dev/null
}

Please give me feedback if this is an acceptable solution, so I can create a pull request.

[aptalca]

Ah, so you're saying that this s6 service exits as soon as it sends a sigterm to the transmission daemon, and the issue is, s6 sends a sigterm to the transmission child processes too early? In that case, delaying the s6 service exits until the transmission daemon can stop the child processes would be a good solution. Please PR and we can test it.

Thanks