[BUG] Service not start with Stable release (4.0.4)

smeretech commented 9 months ago

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior

Transmission not open the respective service and ports in LISTEN mode when start. With version 4.0.3, no issues.

Expected Behavior

It should open the TCP and UDP ports when start

Steps To Reproduce

download the image of stable.
create the Container, using docker-compose, using the YML below.
join to the bash with the command docker exec -it transmission bash
digit netstat -an

Environment

- OS: Synology DSM 7.2.1-69057 Update 2
- How docker service was installed: DSM Container Manager

CPU architecture

x86-64

Docker creation

version: "3.7"

services:
  transmission:
    image: linuxserver/transmission:latest
    container_name: transmission
    ports:
      - 9091:9091
      - 51413:51413
      - 51413:51413/udp
    environment:
      - PGID=100
      - PUID=1043
      - TZ=Europe/Rome
    volumes:
      - /volume1/docker/transmission/data:/config
      - /volume1/docker/transmission/watch:/watch
      - /volume1/docker/transmission/downloads:/downloads
    restart: always
    networks:
      sm_dmz:
        ipv4_address: 192.168.1.3

networks:
  sm_dmz:
    external: true

Container logs

[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:    1043
User GID:    100
───────────────────────────────────────

[custom-init] No custom files found, skipping...

mbisono commented 9 months ago

Can confirm this issue. happens on my synology nas as well.

x-Felix commented 9 months ago

Can confirm this issue. Also cause almost full cpu utilisation with 4.04 build. Use 4.03 build works normally without issue.

bjacobsen commented 9 months ago

Same issue here with 4.0.4-r0-ls209 and ls208 on Synology DSM 7.1.1-42962 Update 6.

Reverting to 4.0.4-r0-ls206, services start and UI is accessible, but no announcements received from trackers and unable to find any peers.

Reverted to 4.0.4-r0-ls199 and it's working.

EkkoG commented 8 months ago

It seems like a DSM relate issue, with docker-compose.yml below

---
version: "3.5"
services:

  transmission:
    #image: linuxserver/transmission:latest
    image: linuxserver/transmission:version-4.0.4-r0
    container_name: transmissionrr
    ports:
      - 9092:9091
    environment:
      - PUID=1026
      - PGID=100
      - TZ=Asia/Shanghai
    restart: unless-stopped

run on macOS desktop, it's fine, and on DSM 6.1, it will failed, with log

transmissionrr  | [migrations] started
transmissionrr  | [migrations] no migrations found
transmissionrr  | ───────────────────────────────────────
transmissionrr  | 
transmissionrr  |       ██╗     ███████╗██╗ ██████╗ 
transmissionrr  |       ██║     ██╔════╝██║██╔═══██╗
transmissionrr  |       ██║     ███████╗██║██║   ██║
transmissionrr  |       ██║     ╚════██║██║██║   ██║
transmissionrr  |       ███████╗███████║██║╚██████╔╝
transmissionrr  |       ╚══════╝╚══════╝╚═╝ ╚═════╝ 
transmissionrr  | 
transmissionrr  |    Brought to you by linuxserver.io
transmissionrr  | ───────────────────────────────────────
transmissionrr  | 
transmissionrr  | To support LSIO projects visit:
transmissionrr  | https://www.linuxserver.io/donate/
transmissionrr  | 
transmissionrr  | ───────────────────────────────────────
transmissionrr  | GID/UID
transmissionrr  | ───────────────────────────────────────
transmissionrr  | 
transmissionrr  | User UID:    1026
transmissionrr  | User GID:    100
transmissionrr  | ───────────────────────────────────────
transmissionrr  | 
transmissionrr  | [custom-init] No custom files found, skipping...

If it success, the log will be

transmission  | [migrations] started
transmission  | [migrations] no migrations found
transmission  | ───────────────────────────────────────
transmission  | 
transmission  |       ██╗     ███████╗██╗ ██████╗ 
transmission  |       ██║     ██╔════╝██║██╔═══██╗
transmission  |       ██║     ███████╗██║██║   ██║
transmission  |       ██║     ╚════██║██║██║   ██║
transmission  |       ███████╗███████║██║╚██████╔╝
transmission  |       ╚══════╝╚══════╝╚═╝ ╚═════╝ 
transmission  | 
transmission  |    Brought to you by linuxserver.io
transmission  | ───────────────────────────────────────
transmission  | 
transmission  | To support LSIO projects visit:
transmission  | https://www.linuxserver.io/donate/
transmission  | 
transmission  | ───────────────────────────────────────
transmission  | GID/UID
transmission  | ───────────────────────────────────────
transmission  | 
transmission  | User UID:    1026
transmission  | User GID:    100
transmission  | ───────────────────────────────────────
transmission  | 
transmission  | [custom-init] No custom files found, skipping...
transmission  | Connection to localhost (127.0.0.1) 9091 port [tcp/*] succeeded!
transmission  | [ls.io-init] done.

EkkoG commented 8 months ago

In my environment, this problem starts with 4.0.4-r0-ls208 and is still fine with 4.0.4-r0-ls207. Although I cannot find the tag of 4.0.4-r0-ls207, the code that causes the problem is probably In this scope https://github.com/linuxserver/docker-transmission/compare/4.0.4-r0-ls206...4.0.4-r0-ls208

EkkoG commented 8 months ago

Same issue here with 4.0.4-r0-ls209 and ls208 on Synology DSM 7.1.1-42962 Update 6.

Reverting to 4.0.4-r0-ls206, services start and UI is accessible, but no announcements received from trackers and unable to find any peers.

Reverted to 4.0.4-r0-ls199 and it's working.

I tested it, and the issue of web pages accessible but not connecting to any nodes started with 4.0.4-r0-ls204 Starting from 204, the network in the container is not connected, you can create a 204 container, run the curl command in it, you will see that there is no response, the network should be unconnected, ping a domain name is normal, that means that DNS is working normally, the possible reason is that the data packet cannot be sent

$ sudo docker exec -ti transmissionrr ping baidu.com
Password: 
PING baidu.com (39.156.66.10): 56 data bytes
64 bytes from 39.156.66.10: seq=0 ttl=50 time=45.654 ms
64 bytes from 39.156.66.10: seq=1 ttl=50 time=45.910 ms
64 bytes from 39.156.66.10: seq=2 ttl=50 time=43.152 ms
64 bytes from 39.156.66.10: seq=3 ttl=50 time=45.016 ms
64 bytes from 39.156.66.10: seq=4 ttl=50 time=45.653 ms
^C
--- baidu.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 43.152/45.077/45.910 ms

But 204 just updates the dependencies, and I don't know why it's causing the network exception https://github.com/linuxserver/docker-transmission/compare/4.0.4-r0-ls203...4.0.4-r0-ls204

sanderkooger commented 8 months ago

Can confirm this issue is present on DSM 7.1.1 too.

docker run -d \ --name=transmission \ -e PUID=1026 \ -e PGID=100 \ -e TZ=Europe/Amsterdam \ -p 9091:9091 \ -p 51413:51413 \ -p 51413:51413/udp \ -v /volume1/docker/transmission/config:/config \ -v /volume1/media/Downloads:/downloads \ -v /volume1/docker/transmission/watch:/watch \ --restart unless-stopped \ lscr.io/linuxserver/transmission:latest

Fails in this exact way

While the following works

docker run -d \ --name=transmission \ -e PUID=1026 \ -e PGID=100 \ -e TZ=Europe/Amsterdam \ -p 9091:9091 \ -p 51413:51413 \ -p 51413:51413/udp \ -v /volume1/docker/transmission/config:/config \ -v /volume1/media/Downloads:/downloads \ -v /volume1/docker/transmission/watch:/watch \ --restart unless-stopped \ lscr.io/linuxserver/transmission:4.0.4-r0-ls206

j0nnymoe commented 8 months ago

We're going to need more detailed information about each users synology such as model/kernel versions please. I've just had transmission working on my unit using: docker run -d --rm --name=transmission --tmpfs /config -p 9091:9091 lscr.io/linuxserver/transmission:latest

DS1019+ | 4.4.302+ #64570 SMP Tue Jun 13 21:40:17 CST 2023 x86_64 GNU/Linux synology_apollolake | DSM 7.2-64570 Update 1

[migrations] no migrations found
usermod: no changes
───────────────────────────────────────

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

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

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

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

User UID:    911
User GID:    911
───────────────────────────────────────

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

sudo docker inspect -f '{{ index .Config.Labels "build_version" }}' transmission
Linuxserver.io version:- 4.0.4-r0-ls210 Build-date:- 2023-12-05T10:35:44+00:00

EkkoG commented 8 months ago

With uname -a

Linux home-dsm 3.10.102 #15284 SMP Sat May 19 04:44:02 CST 2018 x86_64 GNU/Linux synology_broadwell_3617xs

Docker version 20.10.3, build b35e731 docker-compose version 1.28.5, build 1bbbad71

aptalca commented 8 months ago

Fyi kernel 3.10 was released in 2013 and went EOL in 2017. It's ancient. Docker version is close to 3 years old so that's also pretty old.

EkkoG commented 8 months ago

Yes, all of it are very old...

Synology always use an old kernel evan the latest releases 7.2 use kernel 4.4

I will try to upgrade the Docker and try to test again.

aptalca commented 8 months ago

Right, but kernel 4.4 doesn't go EOL until 2027. Yours has been EOL for over 6 years.

EkkoG commented 8 months ago

Yes, the kernel I'm using is EOL, it not very necessary to solve an issue that cause by a very old hardware and kernel, but please have a look the OP's issue, his DSM version is 7.2.1 with kernel 4.4, I think this issue is not a kernel relate issue, when kernel 4.4 can works fine, maybe my old hardware can work too.

j0nnymoe commented 8 months ago

It looks like it could be a combination of kernel and CPU model.

EkkoG commented 8 months ago

I run DSM on PVE, so the CPU is virtualized, the real CPU model is Intel J3455

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 6
model name      : Common KVM processor
stepping        : 1
microcode       : 0x1
cpu MHz         : 1497.646
cache size      : 16384 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology pni cx16 x2apic hypervisor lahf_lm
bogomips        : 2995.29
clflush size    : 64
cache_alignment : 128
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 6
model name      : Common KVM processor
stepping        : 1
microcode       : 0x1
cpu MHz         : 1497.646
cache size      : 16384 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 4
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology pni cx16 x2apic hypervisor lahf_lm
bogomips        : 2995.29
clflush size    : 64
cache_alignment : 128
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 15
model           : 6
model name      : Common KVM processor
stepping        : 1
microcode       : 0x1
cpu MHz         : 1497.646
cache size      : 16384 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 4
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology pni cx16 x2apic hypervisor lahf_lm
bogomips        : 2995.29
clflush size    : 64
cache_alignment : 128
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 15
model           : 6
model name      : Common KVM processor
stepping        : 1
microcode       : 0x1
cpu MHz         : 1497.646
cache size      : 16384 KB
physical id     : 0
siblings        : 4
core id         : 3
cpu cores       : 4
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology pni cx16 x2apic hypervisor lahf_lm
bogomips        : 2995.29
clflush size    : 64
cache_alignment : 128
address sizes   : 40 bits physical, 48 bits virtual
power management:

tomkv commented 8 months ago

Synology DSM 7.2.1-69057 Update 3 (i.e. the absolutely latest one available today), kernel version 3.10.108, platform avoton (i.e. Intel Atom C2538).

Yes, I know that kernel 3.10.x is an ancient one. Synology users do not have much choice, there is no way to build your own kernel and use that instead. It is similar to situation in Android, the kernel is unchangeable part of the whole package.

Btw, different SoCs use different kernel versions, for the same DSM release. That's why you can see kernel 4.4 for some. I guess it depends on the BSP provided by the SoC vendor to Synology.

For me, on the above device, the last version that works is 4.0.4-r0-ls202.

After that, they were not able to contact the trackers; later, with the newer ones, it was not possible to connect to the rpc endpoint. On the NAS, I can see one cpu core spinning up at 100% and nothing happening.

vbaros commented 8 months ago

Can we have a fix for this please? Every other Linuxserver image I tried works perfectly on Synology except this one.

aptalca commented 8 months ago

Can we have a fix for this please? Every other Linuxserver image I tried works perfectly on Synology except this one.

You should read the whole thread. There is likely no fix that we can provide.

tomkv commented 8 months ago

So I've had a closer look, what is really happening.

I have to change my earlier statement: the absolutely latest image version, that works on my Synology is 4.0.4-r0-l203 (not 202).

Since 204, after the container starts, two transmission-daemon processes exist. The first is looping with:

epoll_pwait(4, [], 32, 970, NULL, 8)    = 0

or the -4.0.5-r0-ls212 with:

epoll_pwait(5, [], 32, 999, NULL, 8)    = 0
fsync(4)

so these are just waiting for something; harmless for now.

The second process is looping with:

getrandom(0x7fe34ddd6220, 256, 0)       = -1 ENOSYS (Function not implemented)

so that's the problem... getrandom is a syscall, that was introduced in kernel 3.17, so my 3.10 is going to miss it. And I still do not know which dependency is causing it, the call stack is:

[<ffffffff814a5efe>] system_call_fastpath+0x1c/0x21
[<ffffffffffffffff>] 0xffffffffffffffff

drizuid commented 8 months ago

I think it will be clear now that we do not design around outdated or EOL kernels. When things work on extremely outdated stuff, that is nice, but not something we build for specifically. We will not go out of our way to support something that is end of life, such as in this case. It is unfortunate that your selected vendor (synology) does this to you, but it's not something we can or will dedicate time or effort to.

vbaros commented 2 months ago

With the latest transmission version. At the time of writing 4.0.5. And with the latest Synology Docker package which is now in the beta version and provides Docker version 24.0.2, Transmition works perfectly. Not sure what fixed it, but this issue is no more.

linuxserver / docker-transmission