Using ruby-debug when running rails through foreman

[dunkstewart]

Using ruby-debug when running rails through foreman

[ndbroadbent]

If anyone else reads this issue, tmuxinator is a great alternative that also allows you to start multiple processes. It runs them in different tmux "panes" instead of grouping all of the output, so you are able to use a debugger. Foreman is awesome, but I would highly recommend tmuxinator for development.

[shioyama]

For anyone wanting to use pry in foreman, pry-remote seems to do the trick for me.

[erezny]

If you'd like to run whatever's in your procfile as if you had pasted it into your terminal you can use run rather than start and then your interactive apps will work fine. You just can't run more than one app in one terminal.

Procfile

web: bundle exec rails s

$ foreman run web

[millisami]

+10 For the above concern.

More on the commenting the line inside Procfile.
If I just want not to run some process, we all do put #... for that process not to run, but it does run?
What is the proper way of commenting?

[aaronbrethorst]

I'm trying to understand how to accomplish the same thing as the author. How do you get access to a debug console when you're running your development setup with foreman?

[adahl]

Same problem as author...

[samdalton]

I'm also having this issue when using pry's debugging.

[leehambley]

Is it possible to get an interactive debug console while running rails through foreman in development?

You should look at using remote debuggers… I had some limited success, the notion being that somewhere in an initializer for development mode you set something like the following:

Debugger.wait_connection = true
Debugger.start_remote

There's more documentation here - long story short, the wait_connection = true line should ensure that the debugger pauses for a fixed amount of time (no clue how long) waiting for you to run:

$ rdebug -c

In another terminal, this is how one has to debug when using Passenger, or some other process. I believe that if you skip the wait_remote line, the debug statements are only effective if you previously ran rdebug -c and it is waiting for a server to come up.

YMMV, but I think remote debugging is the way to solve this. Perhaps as an issue, if someone figures it out reliably, they could commit some documentation.

(I also can't say anything about Pry, except that as far as I know it's also only a wrapper around ruby-debug, so the results should be similar.)

[dunkstewart]

Hi leehambley,

That solution works very well indeed! And is some very handy knowledge to have, thank you.

I didn't need to include the Debugger.wait_connection = true line which may be more useful for short running scripts that would otherwise exit before you connect.

The only other complication I had in my setup was that I'm running guard-spork which is using drb on port 8989 as well. I used Debugger.start_remote(nil, 8991) and rdebug -c -p 8991. You could also change guard-spork to use another port.

Thanks again for this info, this will come in very handy.

[millisami]

@dunkstewart Can you post a wiki according to your setup so that it would be easy enough for others?

[vinnividivicci]

@dunkstewart I removed the Debugger.wait_connection = true as well since it was causing issues with nginx. Now I can connect to any of my load balanced instances with the debugger. Thanks guys! @leehambley

[jaredbeck]

For anyone wanting to use pry in foreman, pry-remote seems to do the trick for me.

Two years later, byebug also has support for remote debugging. Use Byebug.start_server and byebug -R. See also Nicholas Gronow's example on SO: https://stackoverflow.com/a/25823241/567762

[nijeesh-rently]

I have been trying out overmind and it great so far.