bad_alloc on rocky 9

[vincentDcmps]

Support guidelines

• I've read the support guidelines

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

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

Description

when I launch container on a rocky linux 9 VM rtorrent pop this log
rtorrent: std::bad_alloc
and rutorrent can't connect to rtorrent so I suppose that he is freezing
I have try to launch same container on arch VM and Rocky 8 VM no issue meet

Expected behaviour

run ccontainer correctly without issue

Actual behaviour

cant use rutorrent

Steps to reproduce

• on a rocky linux 9
• launch docker run crazymax/rtorrent-rutorrent

Docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.9.1-docker)
  compose: Docker Compose (Docker Inc., v2.12.2)
  scan: Docker Scan (Docker Inc., v0.21.0)

Server:
ERROR: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/info": dial unix /var/run/docker.sock: connect: permission denied
errors pretty printing info

Version

• Docker compose version (type docker-compose --version):
• System info (type uname -a):

Docker compose

uname:
linux corwin 5.14.0-70.30.1.el9_0.x86_64 #1 SMP PREEMPT Thu Nov 3 20:29:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Container logs

ervices.d] starting services
2022/11/11 16:22:16 [notice] 514#514: using the "epoll" event method
2022/11/11 16:22:16 [notice] 514#514: nginx/1.21.1
2022/11/11 16:22:16 [notice] 514#514: built by gcc 10.3.1 20211027 (Alpine 10.3.1_git20211027)
2022/11/11 16:22:16 [notice] 514#514: OS: Linux 5.14.0-70.30.1.el9_0.x86_64
2022/11/11 16:22:16 [notice] 514#514: getrlimit(RLIMIT_NOFILE): 1073741816:1073741816
2022/11/11 16:22:16 [notice] 514#514: start worker processes
2022/11/11 16:22:16 [notice] 514#514: start worker process 530
2022/11/11 16:22:16 [notice] 514#514: start worker process 531
rtorrent: std::bad_alloc
[11-Nov-2022 16:22:16] NOTICE: fpm is running, pid 512
[services.d] done.
[11-Nov-2022 16:22:16] NOTICE: ready to handle connections
rtorrent: std::bad_alloc
rtorrent: std::bad_alloc
rtorrent: std::bad_alloc
rtorrent: std::bad_alloc
rtorrent: std::bad_alloc
rtorrent: std::bad_alloc
rtorrent: std::bad_alloc
rtorrent: std::bad_alloc
rtorrent: std::bad_alloc
rtorrent: std::bad_alloc
rtorrent: std::bad_alloc
rtorrent: std::bad_alloc

Additional info

No response

[vincentDcmps]

if Iaunch container with podman no issue meet

[thirstyraven]

I'm facing the exact same issue on Fedora 37 as well.

$ uname -a
Linux <REDACTED> 6.0.15-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Dec 21 18:33:23 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

# No Compose, I just use Docker directly.
$ docker --version
Docker version 20.10.22, build 3a2c30b

[bachmma1]

I faced the same issue on photon OS 5

$ uname -a 
Linux <REDACTED> 6.1.90-1.ph5-esx #1-photon SMP Sat May 18 08:01:52 UTC 2024 x86_64 GNU/Linux

$ docker --version
Docker version 24.0.5, build ced0996

And solved it based on this SO-Article resp. the linked DockerForum

docker run --ulimit nofile=32768:32768 crazymax/rtorrent-rutorrent:latest

The ulimit nofile parameter did the trick. I interpreted the documentation as it is the amount of RAM in MB to set.
So in my case 32 GB of RAM on VM -> forward 32 GB of RAM to the docker container.

Without the ulimit nofile the command ulimit -n showed 1073741816 inside the container. I guess this is too much.

Hope this helps ;)