Newest Transmission update (kinda) breaks the web interface
-
Hello !
Long time no see
I just noticed that since the newest update of Transmission, 5 days ago, I get a lot of 502s on the web interface, and it is generally extremely slow. No idea why this is happening. I tried restarting the app, it does not help. Anybody else seeing this ? -
-
@mehdi nice to see you back
Oh, all the previous update was to update the base image to latest ubuntu.
-
@girish Thanks
After a quick investigation, there appears to be a SegFault in the logs:
Healtheck error: Error: connect ETIMEDOUT 172.18.18.169:90912023-01-10T18:39:17.000Z /app/code/start.sh: line 21: 17 Segmentation fault (core dumped) /usr/local/bin/gosu cloudron:cloudron /usr/local/bin/transmission-daemon --config-dir /app/data/transmission-config/ --foreground Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:90912023-01-10T18:40:18.000Z Starting Transmission... Jan 10 19:40:19 [2023-01-10 18:40:19.591] Transmission 3.00 (bb6b5a062e) started (session.c:769) Jan 10 19:40:19 [2023-01-10 18:40:19.591] RPC Server Adding address to whitelist: transmission.zde.land (rpc-server.c:956) Jan 10 19:40:19 [2023-01-10 18:40:19.591] RPC Server Adding address to whitelist: 127.0.0.1 (rpc-server.c:956) Jan 10 19:40:19 [2023-01-10 18:40:19.591] RPC Server Adding address to whitelist: ::1 (rpc-server.c:956) Jan 10 19:40:19 [2023-01-10 18:40:19.591] RPC Server Serving RPC and Web requests on 0.0.0.0:9091/transmission/ (rpc-server.c:1243) Jan 10 19:40:19 [2023-01-10 18:40:19.591] UDP Failed to set receive buffer: requested 4194304, got 425984 (tr-udp.c:97) Jan 10 19:40:19 [2023-01-10 18:40:19.591] UDP Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf (tr-udp.c:99) Jan 10 19:40:19 [2023-01-10 18:40:19.591] UDP Failed to set send buffer: requested 1048576, got 425984 (tr-udp.c:105) Jan 10 19:40:19 [2023-01-10 18:40:19.591] UDP Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf (tr-udp.c:107) Jan 10 19:40:19 [2023-01-10 18:40:19.591] DHT Generating new id (tr-dht.c:389) Jan 10 19:40:19 [2023-01-10 18:40:19.591] Using settings from "/app/data/transmission-config/" (daemon.c:646) Jan 10 19:40:19 [2023-01-10 18:40:19.591] Saved "/app/data/transmission-config/settings.json" (variant.c:1221) Jan 10 19:40:19 [2023-01-10 18:40:19.591] Loaded 16 torrents (session.c:2170) Jan 10 19:40:19 [2023-01-10 18:40:19.591] Changed open file limit from 1048576 to 1024 (fdlimit.c:408) Jan 10 19:40:19 [2023-01-10 18:40:19.591] Port Forwarding (NAT-PMP) initnatpmp succeeded (0) (natpmp.c:73) Jan 10 19:40:19 [2023-01-10 18:40:19.591] Port Forwarding (NAT-PMP) sendpublicaddressrequest succeeded (2) (natpmp.c:73) Jan 10 19:40:27 /app/code/start.sh: line 21: 16 Segmentation fault (core dumped) /usr/local/bin/gosu cloudron:cloudron /usr/local/bin/transmission-daemon --config-dir /app/data/transmission-config/ --foreground Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:90912023-01-10T18:41:28.000Z Starting Transmission...
-
@girish OK, after a bit more investigation, it appears that the app stops crashing when I remove the transmission-config dir and restart it, then starts crashing again as soon as I add any torrent to download. There appears to be something in the new base image that transmission does not like at all...
-
Also, I can confirm that a rollback to v1.1.0 fixes the problem for me. I am disabling auto updates for now
(btw, it's a bit annoying that there is no way to rollback the version without restoring an old backup Would be nice if it were possible on the interface)
EDIT: btw, I also tried on a clean install of Transmission : same behaviour. Seems to work fine when there are no torrents, then crashes as soon as I add any torrent.
-
Installing a specific version without restoring is only possible via the cloudron cli. Given the fact that often there is datamigration run for updates (even if not the case for transmission here) the data format might be incompatible only causing harder to debug issues. Providing an easier UI for this just makes it look like this is a good idea to do so.
-
Also can confirm that the latest version came with some errors regarding Segmentation Fault.
Had to downgrade to 1.1.0, as per user @mehdi stated.Can we try to check the codebase for a possible bug or is it upstream?
Thanks.
-
-
@mehdi @afonsosantos I can reproduce the crash.
I see this in dmesg:
[3361628.916001] transmission-da[4033116]: segfault at 0 ip 00007efe407dec25 sp 00007efe3f1fb0c0 error 4 in libcrypto.so.3[7efe406fe000+25d000] [3361628.916020] Code: 00 00 00 00 90 f3 0f 1e fa 41 54 41 89 f4 55 48 89 fd 48 81 ec a8 00 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 98 00 00 00 <48> 8b 07 48 83 78 78 00 0f 84 cd 00 00 00 66 0f ef c0 48 63 c6 48
-
OK, so https://github.com/transmission/transmission/discussions/4370 is the upstream bug report. Looks like they recommend using the 4.0 beta instead.
I will revoke this release.
-
It seems even the previous transmission dies with OOM. Looks like maybe something to do with host Ubuntu 22.04. Trying with more memory.
[3363319.142157] Tasks state (memory values in pages): [3363319.142157] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name [3363319.142161] [4038273] 0 4038273 1727 376 49152 69 0 start.sh [3363319.142164] [4038361] 1000 4038361 1163255 23042 2031616 40128 0 transmission-da [3363319.142165] oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=ee5a55896c95564143037faea0b7971e7ce557cd2057bf30bc946570b7ed97e4,mems_allowed=0,oom_memcg=/docker/ee5a55896c95564143037faea0b7971e7ce557cd2057bf30bc946570b7ed97e4,task_memcg=/docker/ee5a55896c95564143037faea0b7971e7ce557cd2057bf30bc946570b7ed97e4,task=transmission-da,pid=4038361,uid=1000 [3363319.142198] Memory cgroup out of memory: Killed process 4038361 (transmission-da) total-vm:4653020kB, anon-rss:90380kB, file-rss:1788kB, shmem-rss:0kB, UID:1000 pgtables:1984kB oom_score_adj:0
-
Apparently, there is a memory leak:
https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/1973084
-
Looks like transmission 4.0 is out.
-
Unfortunately, the memory issue still persists.
-
I have left a comment at https://github.com/transmission/transmission/issues/4786 .
-
I pushed out a new package with 4.0.1. Had to bump up the memory limit to 1GB to make things work a bit more reliably.
-