RUBY_DEBUG_OPEN=true in Procfile.dev breaks running Rails app within Docker container

[hachi8833]

Symptom

• macOS Sonoma 14.1
• Docker version 24.0.6, build ed223b

Recently I got stuck with an issue that any newly generated Rails 7.1.x apps with tailwindcss-rails for running within a Docker container always break when running with bin/dev:

dip dev
[+] Building 0.0s (0/0)                                                                                docker:desktop-linux
[+] Creating 2/0
 ✔ Container enno_docker-chrome-1    Running                                                                           0.0s
 ✔ Container enno_docker-postgres-1  Running                                                                           0.0s
[+] Building 0.0s (0/0)                                                                                docker:desktop-linux
03:09:52 web.1  | started with pid 8
03:09:52 css.1  | started with pid 9
03:09:53 web.1  | system temporary path is world-writable: /tmp
03:09:53 web.1  | /tmp is world-writable: /tmp
03:09:53 web.1  | system temporary path is world-writable: /tmp
03:09:53 web.1  | /tmp is world-writable: /tmp
03:09:53 web.1  | DEBUGGER: Debugger can attach via UNIX domain socket (/app/ruby-debug-sock-0/ruby-debug-UnknownUser-8)
03:09:53 web.1  | => Booting Puma
03:09:53 web.1  | => Rails 7.1.2 application starting in development
03:09:53 web.1  | => Run `bin/rails server --help` for more startup options
03:09:53 web.1  | [8] Puma starting in cluster mode...
03:09:53 web.1  | [8] * Puma version: 6.4.0 (ruby 3.2.2-p53) ("The Eagle of Durango")
03:09:53 web.1  | [8] *  Min threads: 5
03:09:53 web.1  | [8] *  Max threads: 5
03:09:53 web.1  | [8] *  Environment: development
03:09:53 web.1  | [8] *   Master PID: 8
03:09:53 web.1  | [8] *      Workers: 1
03:09:53 web.1  | [8] *     Restarts: (✔) hot (✔) phased
03:09:53 web.1  | [8] * Listening on http://0.0.0.0:3000
03:09:53 web.1  | [8] Use Ctrl-C to stop
03:09:53 web.1  | [8] ! WARNING: Detected running cluster mode with 1 worker.
03:09:53 web.1  | [8] ! Running Puma in cluster mode with a single worker is often a misconfiguration.
03:09:53 web.1  | [8] ! Consider running Puma in single-mode (workers = 0) in order to reduce memory overhead.
03:09:53 web.1  | [8] ! Set the `silence_single_worker_warning` option to silence this warning message.
03:09:53 web.1  | system temporary path is world-writable: /tmp
03:09:53 web.1  | /tmp is world-writable: /tmp
03:09:53 web.1  | DEBUGGER[bin/rails#15]: Debugger can attach via UNIX domain socket (/app/ruby-debug-sock-0/ruby-debug-UnknownUser-8)
03:09:53 web.1  | [8] - Worker 0 (PID: 15) booted in 0.0s, phase: 0
03:09:53 web.1  | #<Thread:0x0000ffff97bf3e10@DEBUGGER__::Server::reader /usr/local/bundle/gems/debug-1.8.0/lib/debug/server.rb:44 run> terminated with exception (report_on_exception is true):
03:09:53 web.1  | /usr/local/lib/ruby/3.2.0/socket.rb:1112:in `lstat': Invalid argument @ rb_file_s_lstat - /app/ruby-debug-sock-0/ruby-debug-UnknownUser-8 (Errno::EINVAL)
03:09:53 web.1  | 	from /usr/local/lib/ruby/3.2.0/socket.rb:1112:in `unix_server_socket'
03:09:53 web.1  | 	from /usr/local/lib/ruby/3.2.0/socket.rb:1167:in `unix_server_loop'
03:09:53 web.1  | 	from /usr/local/bundle/gems/debug-1.8.0/lib/debug/server.rb:500:in `accept'
03:09:53 web.1  | 	from /usr/local/bundle/gems/debug-1.8.0/lib/debug/server.rb:49:in `block in activate'
03:09:53 web.1  | #<Thread:0x0000ffff97bf3460@DEBUGGER__::SESSION@server /usr/local/bundle/gems/debug-1.8.0/lib/debug/session.rb:179 aborting> terminated with exception (report_on_exception is true):
03:09:53 web.1  | /usr/local/lib/ruby/3.2.0/socket.rb:1112:in `lstat': Invalid argument @ rb_file_s_lstat - /app/ruby-debug-sock-0/ruby-debug-UnknownUser-8 (Errno::EINVAL)
03:09:53 web.1  | 	from /usr/local/lib/ruby/3.2.0/socket.rb:1112:in `unix_server_socket'
03:09:53 web.1  | 	from /usr/local/lib/ruby/3.2.0/socket.rb:1167:in `unix_server_loop'
03:09:53 web.1  | 	from /usr/local/bundle/gems/debug-1.8.0/lib/debug/server.rb:500:in `accept'
03:09:53 web.1  | 	from /usr/local/bundle/gems/debug-1.8.0/lib/debug/server.rb:49:in `block in activate'
03:09:53 web.1  | /usr/local/lib/ruby/3.2.0/socket.rb:1112:in `lstat': Invalid argument @ rb_file_s_lstat - /app/ruby-debug-sock-0/ruby-debug-UnknownUser-8 (Errno::EINVAL)
# (repeats indefinitely)

The error Invalid argument @ rb_file_s_lstat - /app/ruby-debug-sock-0/ruby-debug-UnknownUser-8 (Errno::EINVAL) loops indefinitely and creates the following redundant directory ruby-debug-sock-0 for debugging:

Note that the issue does not occur when generating a new Rails 7.1 app with no Docker container environment.

Steps to reproduce

Docker setup is required in your environment.

1. first gem install dip to install dip tool: https://github.com/bibendi/dip
2. clone https://github.com/hachi8833/rails71_tailwindcss and move to the directory
   (The attached Gemfile is generated by bundle init)
3. dip bundle install
4. dip bundle exec rails new . -c tailwind, answering 'yes' to the prompt for overwriting Gemfile
5. dip dev (equivalent to run bin/dev)

Expected behavior: Rails starts normally.
Actual behavior: Debugger emits the errors as above indefinitely.

Survey

I finally found that at least the recent change (adding env RUBY_DEBUG_OPEN=true) in #281 is a trigger of the issue.

# Procfile.dev
web: env RUBY_DEBUG_OPEN=true bin/rails server -p 3000
css: bin/rails tailwindcss:watch

Workaround

We can have some workarounds such as:

• Remove env RUBY_DEBUG_OPEN=true from Procfile.dev
• Disable debug gem in Gemfile
• Add require: false to debug gem in Gemfile

Proposition

As shown above, the added env RUBY_DEBUG_OPEN=true disturbs generating new Rails app for Docker container.

While we have some workarounds as above, I think the benefit of adding env RUBY_DEBUG_OPEN=true as a default is at least limited and perhaps an overkill. I believe that purely generated Rails app with tailwindcss-rails should run normally in Docker container, without any tweaks.

In the current situation, the reason the debug gem glitched in Docker container seems complicated and is unsure for me, but it seems that ruby/debug#982 might be relevant with it.
I think the issue should be resolved first before adding env RUBY_DEBUG_OPEN=true to Procfile.dev. At least the ruby-debug-sock-0 directory should be created under app/tmp dir.

So I hope you'd remove env RUBY_DEBUG_OPEN=true from Procfile.dev until the issue of debug gem and Docker is resolved. I guess just adding a description to activate env RUBY_DEBUG_OPEN=true on README so that users can manually activate remote debugging is sufficient for a while.

cc @duduribeiro

Update: st0012 kindly mentioned that the relevant issue ruby/debug#797

[flavorjones]

@elia This seems like it would impact jsbundling-rails and cssbundling-rails as well. What do you think we should do?

[elia]

@flavorjones I tried a few options, looks like adding RUBY_DEBUG_LAZY=true as an export in bin/dev or as an env in Procfile.dev also fixes the issue, at least until a debugger session is started.

That to me looks like the easiest for both worlds, fixing the happy path.

I'm not sure how to fix the tmpdir permission issue in the docker environment or if exposing a port could be enough, but once someone figures out the issue I guess the solution could be built into the default.

[elia]

@flavorjones @hachi8833

I just opened #292, please let me know if anyone wants to help porting it to other bundling repos, otherwise I'll do it once it's merged.

[flavorjones]

I've merged #292. Will cut a release shortly! ❤️