Foreman / Passenger - address is already in use #141
Comments
|
@michaelimstepf Sorry for taking this long to reply. If I ever use foreman again, I'll have a look at it. |
|
Thanks. I think the problem is with Passenger, not foreman. |
|
Ok, changing the title to reflect that. |
deivid-rodriguez
changed the title
|
@michaelimstepf Are you still getting this issue with latest Thanks! |
|
@deivid-rodriguez Thx, would be great if you could look into since we waste so much time stopping foreman and booting the super slow Webrick server every time we need to debug locally. # Gemfile.lock
byebug (6.0.2)
passenger (5.0.16)
# config/development.rb
require 'byebug'
Byebug.wait_connection = true
Byebug.start_server('localhost', 4000) # see also http://stackoverflow.com/questions/22794176/how-to-use-byebug-with-a-remote-process-e-g-pow
# Procfile
web: bundle exec passenger start -p $PORT --max-pool-size 2
worker: bundle exec sidekiq -c 2 -v
clock: bundle exec clockwork lib/clock.rb |
|
Thanks, but it's not enough. I'm in front of my terminal, which commands do I run to trigger the error? Also, did you make sure that the port is not already in use? |
|
Thx for looking into this. Just run 'foreman start' to boot the server. I tried lots of different On Mon, 31 Aug 2015 21:59 David Rodríguez notifications@github.com wrote:
|
Remember that I'm in front of my computer, not in front of yours. |
|
Sure. Please follow the code outlined in my post earlier including Thx for your help. It's almost midnight here, I can quickly connect on Skype if you like, otherwise I can reply tmr. Thx |
|
As noted in the Gemfile.lock above, gem |
|
Of course, I'm just trying emphasize that the code outlined is not enough for me. I want you to do all the setup job for me and create a sample application that reproduces the error. You are currently the only person getting the error so it's very likely that I'll take the time to set all this up for myself and still won't be able to reproduce it. |
|
Got it. You're going to hate me but I created a sample app and couldn't reproduce the issue. Strangely enough, I have the problem and both my personal laptop and my work laptop and my colleague has the same issue. I'll dig into it tomorrow, it might have to do with some temp file that Passenger is writing that we can delete to free ports, not sure yet. Anyways, sorry for wasting your time, I would not have posted it if it didn't occur on 3 laptops. Thanks for your help. |
|
Don't worry about it! Please reopen if you figure out a way I can see the issue for myself. |
|
I've tried a few things on two different laptops but still can't figure it out. Here's the sample app: https://github.com/michaelimstepf/byebug, would be awesome if you could have a look at it. I can get it work if I either But in our dev setup we need to be able to debug (non background tasks) while having background tasks running. Steps to reproduce:
|
|
I have had the same issue. The problem is that you have (like me) multiple rails processes starting in your Procfile. As every one of them runs the initializer, at least the second process crashes, as the port is (legitimately) already in use . So what I did as a workaround is something like this, to prevent following processes to crash:
Don't forget that the process you want to debug has to be obviously the first one in your Procfile. However - if your first process is too lazy you can still get into some other race condition... ;) Andreas |
|
Thanks for your reply. I've added the |
|
I think the byebug/remote function is a bit difficult to handle for larger rails apps, as you can hardly control in which process it will be initialized (and will therefore be functional). I tried the following (Procfile): and then in initializer/byebug.rb: Now I even have two listening processes: But hitting a 'byebug' command crashes the app with an Errno::EPIPE (Broken pipe) exception. However - lacking time I switched back to console debugging for the moment. Wishing you more luck, |
|
Thanks @mollat. @deivid-rodriguez What are your thoughts on this, is byebug definitely not suitable for debugging apps that have background workers, cron jobs, etc? |
|
I think it is suitable, it just needs some love. |
|
JFYI: for RubyMine we are starting "dispatcher": server which receives requests from newly created processes and give them port they can use to connect to debugger. |
|
@os97673 Thanks for that information, that might help future contributors! 😄 |
|
Thanks guys, is there any workaround or hack we can use in the meantime? |
|
Not that I know of. |
|
I am getting the exact same issues.. whenever I start the rails console, spring will also try to start an instance of byebug server. |
|
I was able to connect to the byebug server and get a stack trace if i make sure the pid listening to the port is in fact the rails server and not spring.. If I killed the byebug remote client process during a debugging session, I will receive a Broken pipe error from the front end for further hits on the 'byebug' command. Digging into netstat, there seems to be a stuck close_wait port that does not release until the front end is restarted.. (such as touch tmp/restart in passenger) tcp 0 0 127.0.0.1:1048 0.0.0.0:* LISTEN Why is it stuck waiting? Is it because its still "debugging"? |
|
Hi everyone, some issues about remote debugging are getting fixed in #406, and also a |
|
I ran into this today. It was due to Spring starting the Byebug server in the background. What I ended up doing is using the |
I've followed the tutorial and added this to
config/development.rb:When starting foreman, I get the error below. I've tried many different ports, the error message is always the same =(.
The text was updated successfully, but these errors were encountered: