rtorrent failures since 4.3.5-5.1

antoine-morvan commented 2 days ago

Support guidelines

[X] I've read the support guidelines

I've found a bug and checked that ...

[X] ... the documentation does not mention anything about my problem
[X] ... there are no open or closed issues that are related to my problem

Description

Since a recent update of the image, I get some errors from rutorrent. I cleared my previous sessions and started with a clean, minimal setup (see docker compose config below). I then tested with a torrent from ubuntu (server image from https://ubuntu.com/download/alternative-downloads ).

The error I get within ruTorrent when adding a torrent is like this (instanteous after adding) :

That seems to indicate the XMLRPC link is down and rtorrent is not responding. When checking the logs from the container, I can indeed observe some error messages (keeps printing the message, just post 2 iterations here) :

rutorrent-1  | Caught Illegal instruction, dumping stack:
rutorrent-1  | Stack dump not enabled.
rutorrent-1  | Caught Illegal instruction, dumping stack:
rutorrent-1  | Stack dump not enabled.

I can reproduce with versions 4.3.5-5.1 and 4.3.6-6.0, and cannot reproduce with version 4.3.5-4.0 (did not test prior versions).

Expected behaviour

Should not produce errors, as it was working fine with previous versions.

Actual behaviour

Produces errors.

Steps to reproduce

Startup a fresh rtorrent+rutorrent instance using a docker compose
add a torrent
observe the error

Docker info

Client: Docker Engine - Community
 Version:    27.3.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.17.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.29.7
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 21
 Server Version: 27.3.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7f7fdf5fed64eb6a7caf99b3e12efcf9d60e311c
 runc version: v1.1.14-0-g2c9f560
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.1.0-25-amd64
 Operating System: Debian GNU/Linux 12 (bookworm)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 1.903GiB
 Name: test
 ID: ddd87cfc-18f9-4c6e-8ce1-2861def5c331
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

Docker Compose config

name: docker
services:
  rutorrent:
    environment:
      PGID: "1000"
      PUID: "1000"
      RT_INC_PORT: "49161"
      TZ: Europe/Paris
    image: crazymax/rtorrent-rutorrent:4.3.5-5.1
    networks:
      default: null
    ports:
      - mode: ingress
        target: 49161
        published: "49161"
        protocol: tcp
      - mode: ingress
        target: 8080
        published: "8080"
        protocol: tcp
    restart: always
    ulimits:
      nofile:
        soft: 32000
        hard: 40000
      nproc: 65535
networks:
  default:
    name: docker_default

Logs

N/A

Additional info

I could not reproduce on my desktop machine : this only happens on my server hosted at OVH. I even tried with a debian VM with similar version, kernel, docker version, etc., but still could not reproduce.

antoine-morvan commented 2 days ago

I dag a bit more into the rtorrent updates from stickz. This commit https://github.com/stickz/rtorrent/commit/8448b61ec3c1f7ffdebd4f2f5b5dd0b21ffad785#diff-ee3c54847fe9ce700a487ca77c6d35a3ef86393cebea800d9213a1ba3e511d62R137 -- included in stickz/rtorrent 4.1 (https://github.com/stickz/rtorrent/releases/tag/v4.1-0.9.8-0.13.8 -- adds support for popcnt instruction from SSE 4.2 ; which brings performance improvements. However, binaries built on a SSE4 capable system will not be able to run on a non SSE4 capable system. Unfortunately, my old OVH server does not have SSE4 support (Intel Atom N2800), and seems to fall into this pitfall...

Not sure how this should be addressed : either disables this SSE4 instruction from the build flags (with the implied performance drop), or explicitly drop support for systems that do not have SSE4 , or provide several images , or advise people to docker build for these unsupported systems ... #discuss :D

There are frameworks for building binaries with automatic dispatch depending of the CPU support (I am thinking of Google Highway https://google.github.io/highway/en/master/index.html), but that would require rtorrent updates, most likely deep restructuring.

antoine-morvan commented 2 days ago

I built the image on my server, and it is still throwing the same error : I doubt recommending building the image, nor trying to disable popcnt using build flags makes sense actually.

I also built the image from latest commit (020c5bc0b48ed91025c527108a32705aa2f4eb14), just changing the rtorrent version to older hash, testing 4.0 and 4.1

with version 4.0 (5e93c1dc03a613e916877a135439a2643fdf9c48) : success
with version 4.1 (8448b61ec3c1f7ffdebd4f2f5b5dd0b21ffad785) : fail

I conclude this is not an issue with the image, but with rtorrent. I am opening an issue over there; I let current issue open as either this will need a rtorrent update, or a documentation update for dropping old CPUs support ^^

crazy-max / docker-rtorrent-rutorrent