Transmission web interface not responding/timing out

LSIO Discussion Container Support
1

How do I go about debugging web interface timing out? Logs don’t indicate any issues, but they are also not showing any information about connections to web interface. Is there any way to increase verbosity?

#docker logs transmission
[migrations] started
[migrations] no migrations found
───────────────────────────────────────

      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝

   Brought to you by linuxserver.io
───────────────────────────────────────

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    1000
User GID:    1000
───────────────────────────────────────

[custom-init] No custom files found, skipping...
Connection to localhost (127.0.0.1) 9091 port [tcp/*] succeeded!
[ls.io-init] done.

I tried transmission-cli directly from the container to exclude any network related issues and am still getting timeout:

# transmission-remote -b --list
posting:
--------
{"arguments":{"fields":["error","errorString","eta","id","isFinished","leftUntilDone","name","peersGettingFromUs","peersSendingToUs","rateDownload","rateUpload","sizeWhenDone","status","uploadRatio"]},"method":"torrent-get","tag":6}
--------
* Couldn't find host localhost in the .netrc file; using defaults
* Host localhost:9091 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:9091...
* connect to ::1 port 9091 from ::1 port 32938 failed: Connection refused
*   Trying 127.0.0.1:9091...
* Connection timed out after 60001 milliseconds
* Closing connection

Something is listening on port 9091:

# netstat -ln|grep 9091
tcp      129      0 0.0.0.0:9091            0.0.0.0:*               LISTEN

This started after I moved container to new server, but all the other containers I move started up without any problems. (radarr, sonarr, prowlarr)

2

Share the compose or docker run , note we do not support portainer or any other ui for deploying our containers (with the exception of unraid)

3

Nice and boring:
docker run --rm --replace -d --name=transmission -e PUID=1000 -e PGID=1000 -e TZ=America/Los_Angeles -p 9091:9091 -p 51413:51413 -p 51413:51413/udp -v transmission:/config -v /mnt/downloads:/downloads lscr.io/linuxserver/transmission

4

Boring is good. Can you use /tmp/test:/config
Replacing your config mount and see what happens? Stop your currently running instance first and ensure 9091 is freed up

5

Web interface works without issues with blank/default config file, but I don’t think I made any changes significant enough to break web interface:

19c19
<     "dht-enabled": false,
---
>     "dht-enabled": true,
23c23
<     "encryption": 2,
---
>     "encryption": 1,
39c39
<     "pex-enabled": false,
---
>     "pex-enabled": true,
53c53
<     "rpc-password": "pass321",
---
>     "rpc-password": "pass123",
63,64c63,64
<     "script-torrent-done-enabled": true,
<     "script-torrent-done-filename": "/config/unrar.sh",
---
>     "script-torrent-done-enabled": false,
>     "script-torrent-done-filename": "",
79c79
<     "utp-enabled": true,
---
>     "utp-enabled": false,

Content of /config/unrar.sh just in case:

#!/bin/bash

mkdir -p /downloads/tmp/$TR_TORRENT_NAME

/usr/bin/unrar e $TR_TORRENT_DIR/$TR_TORRENT_NAME/*.rar /downloads/tmp/$TR_TORRENT_NAME/
mv /downloads/tmp/$TR_TORRENT_NAME/* $TR_TORRENT_DIR/$TR_TORRENT_NAME/
6

I’m on mobile, so reading through all that isn’t simple, but if it works without changes, I think you know what to do. Introduce your changes one at a time until it breaks (or works because magic)

7

Well, its not config issue. Definitely something in resume or torrents dir. I have a LOT of torrents.
I tried enabling trace level logging, but it stops on a completely random operation leading me to believe something deeper in OS causes transmission to freeze.
[2024-04-01 18:46:58.452] trc bandwidth.cc:189 peer #1 of 3 used 3000 bytes in this pass (bandwidth.cc:189)

I suspect the problem had something to do with NTFS FUSE driver. I only expected bad performance (which I was OK with), but it seems it was totally broken. I switched to BTRFS and transmission loaded without any issues. So I’m marking as solved, but I’m not 100% what the issue was. Definitely nothing to do with LSIO transmission container though.

8

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.