$COMMAND is only started when SIGINT is sent to rdebug-ide

[fstephany]

I'm trying to start a debug session and get the following:

$ bundle exec rdebug-ide --host 0.0.0.0 --port 1234 --dispatcher-port 26162 -- bin/rails s
Fast Debugger (ruby-debug-ide 0.6.1, debase 0.2.2, file filtering is supported) listens on 0.0.0.0:1234
^C=> Booting Puma
=> Rails 5.2.0 application starting in development 
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.11.4 (ruby 2.5.1-p57), codename: Love Song
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3000

It seems that the rails server is only started when I press ctrl+c. I can wait as long as I want after Fast Debugger (...) listens on 0.0.0.0:1234 is printed, the server does not start.

• ruby 2.5.1
• Rails 5.2.0
• debase 0.2.2
• ruby-debug-ide 0.6.1

I get this behavior in macOS and in a Docker container.

[fstephany]

I've tried with the 0.7.0.beta4 version and got the same result:

$ bundle exec rdebug-ide --host 0.0.0.0 --port 1234 --dispatcher-port 26162 -- bin/rails s
Fast Debugger (ruby-debug-ide 0.7.0.beta4, debase 0.2.2, file filtering is supported) listens on 0.0.0.0:1234
^C=> Booting Puma
=> Rails 5.2.0 application starting in development 
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.11.4 (ruby 2.5.1-p57), codename: Love Song
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop

[afr1983]

I'm running VS Code with an extension to integrate with rdebug-ide.

I need to attach VS Code to the rails app in order for rdebug-ide to execute $COMMAND. I think rdebug-ide was designed so that the app is only started when you launch it from the IDE, instead of running standalone and then attaching occasionally. The latter is how I commonly debug my apps, so I'd like to leave it always running.

[leanazulyoro]

@fstephany Have you figured it out? I'm facing the same issue. The command only runs when I press Ctrl+C or if I go on and launch the remote debug session from VScode. It works great but I'll really like that the command would run initially, and not force me to attach to the debugger in order for it to run. I'd like the have the debugger as an option, not constantly attached.

[fstephany]

Nope, I ended up using byebug. It's a bit less practical but works fine (on a local macOS env and in Docker).

[ViugiNick]

@fstephany, @leanazulyoro, @afr1983 Did you try 0.2.3.beta2 version of a debase gem?

[ViugiNick]

@fstephany, @leanazulyoro, @afr1983 After the Fast Debugger (ruby-debug-ide 0.7.0.beta4, debase 0.2.2, file filtering is supported) listens on 0.0.0.0:1234 debugger is waiting for connections (something like nc 127.0.0.1 1234)

[chriso0710]

I stumbled across this thread. I initially thought I had this problem too. But actually the debugger works as designed. The debugger waits for an IDE to connect, you don't have to press CTRL-C. When the connection is established, it starts the rails server automatically. After updating debase to the latest release from github I had no problems connecting and debugging with VS code. Debugging in VS code is faster and easier than byebug IMHO.

$ rdebug-ide --host 0.0.0.0 --port 1234 --dispatcher-port 26162 -- bin/rails s
Fast Debugger (ruby-debug-ide 0.6.1, debase 0.2.3.beta5, file filtering is supported) listens on 0.0.0.0:1234
=> Booting Puma
=> Rails 5.2.1 application starting in development 
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.12.0 (ruby 2.5.3-p105), codename: Llamas in Pajamas
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3000
...

My VS code launch config

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for rdebug-ide",
            "type": "Ruby",
            "request": "attach",
            "remoteHost": "127.0.0.1",
            "remotePort": "1234",
            "remoteWorkspaceRoot": "${workspaceRoot}",
            "cwd": "${workspaceRoot}"
        }
    ]
}

P.S.: Starting the debugger also works from foreman procfile.

[tillkolter]

I have the same problem. Debugging only works after Ctrl + C to the debug-ide process. Running the exact same launch config as @chriso0710 but no progress.

[tillkolter]

@fstephany, @leanazulyoro, @afr1983 and to who it may concern:

TLDR: Make sure, to remove unrelated breakpoints from other projects.

[Edit]: Make sure, that all breakpoints in your list are enabled

---

I was struggling with the same issue on my machine: RDebug on the command line was not starting the rails server unless I did Ctrl+C once.

My colleague right next to me, who jumped into the project a few days later with a fresh installation of VSCode (we are both just on-boarding for a Ruby project coming from other IDE backgrounds) was not facing any issues and could debug from his first launch. I already had given up, but I couldn't accept that it was working for him and not for me, we were both running on Docker with same env variables, so in theory the basic project setup or any kind version mess didn't seem to be a problem.

The attached process and the debugger seemed to be connected, because killing the attached process would kill the debugger process.

My last resort was Wireshark to see what was going on the TCP networking level. Finally I had my Heurika moment. The attached IDE debug process was sending breakpoint positions to the debugger server process, including breakpoints from other projects. I removed all breakpoints and restarted the process and click – the server starts and I was able to break in my code.

Hope this helps anyone setting up his debugger.

[ViugiNick]

@tillkolter So the problem is on VSCode plugin side (of it's related to sending breakpoints)?

[tillkolter]

@ViugiNick I am sorry, I don't know the exact place in code that is responsible for this problem. I wish I had more time to investigate what was really going on under the hood, was hoping that I could at least contribute by point toward the potential root of the problem. At least in my case clearing all breakpoints solved the issue.

[tillkolter]

Meanwhile, I could narrow it down for my case that it does not matter whether the spurious breakpoints lie within the same project or outside. What made the difference, was whether all breakpoints were enabled or not. As soon as I had one disabled breakpoint in the list, the server would not start.

[baelter]

Removing disabled breakpoint solved it for me as well.

[vedmant]

So there is no way to attach to debug server after server is started? I'm not always using debug, it looks like to use debug only when I need it I need to edit docker compose file each time?

[ttemrahcelik]

Looks like they added a skip_wait_for_start option as of 0.7.1.beta1: https://github.com/ruby-debug/ruby-debug-ide/pull/167

Which works just fine as far as I can tell.