debug: Connection refused error after updating to 1.6.X in a Rails project running inside docker

Your environment

ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [aarch64-linux]
rdbg -v: working: rdbg 1.5.0, non-working rdbg 1.6.X

Describe the bug I’m using the official Ruby 3.1.2-slim docker image. After updating the debug gem from 1.5.0 to 1.6.X, I cannot attach to the running process any more.

I’m running a Rails project with the latest Rails version (7.0.4) and the Puma web server. This is the command I’m running:

rdbg --open --nonstop -c -- rails s -b '0.0.0.0'

Using debug 1.5.0, all is well:

❯ dc exec web rdbg -A
# No sourcefile available for /usr/local/bundle/gems/puma-5.6.5/lib/puma/single.rb
=>#0    [C] Thread#join at /usr/local/bundle/gems/puma-5.6.5/lib/puma/single.rb:61
  #1    Puma::Single#run at /usr/local/bundle/gems/puma-5.6.5/lib/puma/single.rb:61
  # and 15 frames (use `bt' command for all frames)

Stop by SIGURG
(rdbg:remote) c    # continue command

Socket name (automatically chosen by the debug gem): /tmp/ruby-debug-sock-0/ruby-debug-ruby-debug-1

Using debug 1.6.X, the connection does not work any more:

/usr/local/lib/ruby/3.1.0/socket.rb:64:in `connect': Connection refused - connect(2) for /tmp/ruby-debug-sock-0/ruby-debug-UnknownUser-1 (Errno::ECONNREFUSED)
        from /usr/local/lib/ruby/3.1.0/socket.rb:64:in `connect_internal'
        from /usr/local/lib/ruby/3.1.0/socket.rb:137:in `connect'
        from /usr/local/lib/ruby/3.1.0/socket.rb:1078:in `unix'
        from /usr/local/bundle/gems/debug-1.6.0/lib/debug/client.rb:158:in `connect_unix'
        from /usr/local/bundle/gems/debug-1.6.0/lib/debug/client.rb:108:in `initialize'
        from /usr/local/bundle/gems/debug-1.6.0/exe/rdbg:31:in `new'
        from /usr/local/bundle/gems/debug-1.6.0/exe/rdbg:31:in `<top (required)>'
        from /app/bin/rdbg:29:in `load'
        from /app/bin/rdbg:29:in `<main>'

Socket name (automatically chosen by the debug gem): /tmp/ruby-debug-sock-0/ruby-debug-UnknownUser-1

Notice the change in the socket name, maybe this has something to do with this issue? The socket does exist, though, and permissions seem correct.

To Reproduce Update debug to 1.6.X. I’ve tried all released 1.6 versions, none of them is working. Going back to 1.5 resolves the issue for me.

Expected behavior rdbg -A connects to the running process.

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 1
Comments: 15

Most upvoted comments

Hi @ko1, thank you for your reply. I added a simple Rails app for reproduction here:

https://github.com/ralph/ruby-debug-761

I tried using the official docker guide (where not outdated) to be as standards compliant as possible: https://docs.docker.com/samples/rails/

You should be able to start the server by running dc build followed by dc up. Note dc: aliased to docker compose.

Start command is here: https://github.com/ralph/ruby-debug-761/blob/main/docker-compose.yml#L15

I try to connect to the debugger like this:

dc exec web rdbg -A
/usr/local/lib/ruby/3.1.0/socket.rb:64:in `connect': Connection refused - connect(2) for /tmp/ruby-debug-sock-0/ruby-debug-UnknownUser-1 (Errno::ECONNREFUSED)
        from /usr/local/lib/ruby/3.1.0/socket.rb:64:in `connect_internal'
        from /usr/local/lib/ruby/3.1.0/socket.rb:137:in `connect'
        from /usr/local/lib/ruby/3.1.0/socket.rb:1078:in `unix'
        from /usr/local/bundle/gems/debug-1.6.2/lib/debug/client.rb:158:in `connect_unix'
        from /usr/local/bundle/gems/debug-1.6.2/lib/debug/client.rb:108:in `initialize'
        from /usr/local/bundle/gems/debug-1.6.2/exe/rdbg:31:in `new'
        from /usr/local/bundle/gems/debug-1.6.2/exe/rdbg:31:in `<top (required)>'
        from /usr/local/bundle/bin/rdbg:25:in `load'
        from /usr/local/bundle/bin/rdbg:25:in `<main>'

I also added a branch with debug 1.5 installed, which works: https://github.com/ralph/ruby-debug-761/tree/ruby-debug-1-5

dc exec web rdbg -A
# No sourcefile available for /usr/local/bundle/gems/puma-5.6.5/lib/puma/single.rb
=>#0    [C] Thread#join at /usr/local/bundle/gems/puma-5.6.5/lib/puma/single.rb:61
  #1    Puma::Single#run at /usr/local/bundle/gems/puma-5.6.5/lib/puma/single.rb:61
  # and 16 frames (use `bt' command for all frames)

Stop by SIGURG
(rdbg:remote) c    # continue command

ralph on Nov 18, 2022

I was able to eliminate the EADDRINUSE flood by setting Puma workers to 0 (disable cluster mode) with TCP.

I’m going to do some more testing but I wonder if it has to do with the default behavior of RUBY_DEBUG_FORK_MODE being to init debugger for both parent and child, with Puma in cluster mode (workers >= 1) I could see this being the cause.

seankibler on Jul 12, 2023

Sorry, I can’t help with that. I’m using the socket, not TCP.

ralph on Nov 18, 2022