You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Rails server hangs, doesn't stop at breakpoints #208
I have three problematic scenarios, and all are preventing me from properly debugging the server using VSCode and Docker.
Scenario 1:
I start the server in the container using rdebug-ide --host 0.0.0.0 --port 6969 --dispatcher-port 6969 -- bin/rails s -p 3000 -b 0.0.0.0
When I attach the IDE, the server starts normally. When I try to make a request, it hangs and doesn't reach the breakpoint in VSCode. Eventually the console will print timeout messages:
[87] Puma starting in cluster mode...
[87] * Version 3.12.0 (ruby 2.6.5-p114), codename: Llamas in Pajamas
[87] * Min threads: 5, max threads: 5
[87] * Environment: development
[87] * Process workers: 2
[87] * Preloading application
[87] * Listening on tcp://0.0.0.0:3000
[87] Use Ctrl-C to stop
[87] ! Terminating timed out worker: 89
[87] ! Terminating timed out worker: 91
[87] ! Terminating timed out worker: 93
[87] ! Terminating timed out worker: 95
[87] ! Terminating timed out worker: 97
[87] ! Terminating timed out worker: 99
[87] ! Terminating timed out worker: 101
[87] ! Terminating timed out worker: 103
Scenario 2:
I start the server without the dispatcher port using rdebug-ide --host 0.0.0.0 --port 6969 -- bin/rails s -p 3000 -b 0.0.0.0
I attach the IDE and the server then operates normally when it receives requests, but will not stop on VSCode breakpoints.
Scenario 3:
I use docker-compose to start the container using the configuration:
The server operates normally, and hangs for the requests where breakpoints are set, but breakpoints aren't reached in VSCode.
I see people using the same port as configured in the launch.json for the dispatcher port, and I also see them using 26162, which seems like a VSCode-internal debugging port. Which one should be used? Any other ideas what's wrong with my configuration?
The debugger will flag your breakpoint when it hits the file on that line, but since the file doesn't exist for the unix system, it will never break
Are you actually staying on-topic? This is an issue about Rails server hanging when the code is about to hit the breakpoint. (Browsing to a location that would not break will not hang the server)
If this is offtopic, please create a new ticket, and preferably submit a PR since you seem to have a solution to the issue you are facing.
Activity
Nowaker commentedon Dec 19, 2020
Hitting the same problem with VS Code recently. Just a couple days.
Nowaker commentedon Dec 19, 2020
My environment is: Puma 4.2.0, Rails 5.0, 5.1, 5.2
Nowaker commentedon Apr 29, 2021
No. Arch Linux.
Are you actually staying on-topic? This is an issue about Rails server hanging when the code is about to hit the breakpoint. (Browsing to a location that would not break will not hang the server)
If this is offtopic, please create a new ticket, and preferably submit a PR since you seem to have a solution to the issue you are facing.
saviu-u commentedon Apr 29, 2021
I missed the topic then, sorry, I'm removing the comment
elliotwesoff commentedon Apr 29, 2021
In case this is a question of environment, this was on Pop OS, an Ubuntu based distro geared toward dev work. I haven't tested this on any other OS.
drmdrew commentedon May 11, 2021
I wonder if this issue is due to puma running in cluster mode versus single mode?
Setting
PUMA_WORKERS=0may help in this case like it did here... worth checking at least: