Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rails 5 - Puma default port does not take effect #24435

Closed
ghost opened this issue Apr 5, 2016 · 33 comments

Comments

Projects
None yet
@ghost
Copy link

commented Apr 5, 2016

Especially prevents from comfortable SOA development, as you can't start different services at the same time and test the interactions between them.

Steps to reproduce

  1. Create new rails project (normal or api).
  2. Change a line in config/puma.rb to: port ENV.fetch("PORT") { 3010 }.
  3. Run $ rails s.

Expected behavior

Puma server should run on port 3010.

Actual behavior

Listening on tcp://localhost:3000
Puma server runs on port 3000 instead of 3010.

System configuration

Rails version: 5.0.0.beta3

Ruby version: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-linux]

@prathamesh-sonpatki

This comment has been minimized.

Copy link
Member

commented Apr 5, 2016

I think this issue has been fixed on master. cc @schneems

@vipulnsward vipulnsward added the railties label Apr 5, 2016

@vipulnsward

This comment has been minimized.

Copy link
Member

commented Apr 5, 2016

This is not supported right now, unless you run with puma, which is working as expected.
Richard seems to be working on it vipulnsward@5563c32 but as of now its not supported(See puma/puma#512 for more info)

Going to close for now, as this is more of feature request right now.

@schneems

This comment has been minimized.

Copy link
Member

commented Apr 5, 2016

This should work on master. Can you please re-try with rails master and let me know if it is working? Make sure that spring is stopped.

@schneems schneems reopened this Apr 5, 2016

@vipulnsward

This comment has been minimized.

Copy link
Member

commented Apr 5, 2016

@vipulnsward

This comment has been minimized.

Copy link
Member

commented Apr 5, 2016

If this is valid, I believe puma/puma#939 is a valid issue too.

@schneems

This comment has been minimized.

Copy link
Member

commented Apr 7, 2016

This works for me

$ env PORT=4000 rails server
=> Booting Puma
=> Rails 5.0.0.beta3 application starting in development on http://localhost:4000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
/Users/richardschneeman/Documents/projects/codetriage/config/initializers/git_hub_bub.rb:2: warning: already initialized constant GitHubBub::Request::USER_AGENT
/Users/richardschneeman/.gem/ruby/2.3.0/gems/git_hub_bub-0.0.6/lib/git_hub_bub/request.rb:7: warning: previous definition of USER_AGENT was here
/Users/richardschneeman/Documents/projects/codetriage/config/initializers/git_hub_bub.rb:3: warning: already initialized constant GitHubBub::Request::RETRIES
/Users/richardschneeman/.gem/ruby/2.3.0/gems/git_hub_bub-0.0.6/lib/git_hub_bub/request.rb:12: warning: previous definition of RETRIES was here
/Users/richardschneeman/Documents/projects/codetriage/config/initializers/git_hub_bub.rb:4: warning: already initialized constant GitHubBub::Request::GITHUB_VERSION
/Users/richardschneeman/.gem/ruby/2.3.0/gems/git_hub_bub-0.0.6/lib/git_hub_bub/request.rb:8: warning: previous definition of GITHUB_VERSION was here
[59980] Puma starting in cluster mode...
[59980] * Version 3.0.0.rc1 (ruby 2.3.0-p0), codename: Schneems Sleak Shoes
[59980] * Min threads: 5, max threads: 5
[59980] * Environment: development
[59980] * Process workers: 2
[59980] * Preloading application
[59980] * Listening on tcp://localhost:4000
[59980] Use Ctrl-C to stop
[59980] - Worker 0 (pid: 60018) booted, phase: 0
[59980] - Worker 1 (pid: 60019) booted, phase: 0

Are you using Puma 3.0 or above?

@vipulnsward

This comment has been minimized.

Copy link
Member

commented Apr 7, 2016

@schneems so the above would work because of

Port: ENV.fetch('PORT', 3000).to_i,
.

This issue is related to changing port value in config/puma.rb, (example-https://gist.github.com/vipulnsward/74c9966f7dd6d57828092a26418b1b51)
and just running rails server

@schneems

This comment has been minimized.

Copy link
Member

commented Apr 8, 2016

I think this is an issue in puma, I posted a comment there

@schneems

This comment has been minimized.

Copy link
Member

commented Apr 22, 2016

We could add some logic in Rails to not specify port if puma is bundled and a config/puma.rb file exists.

WDYT?

@vipulnsward

This comment has been minimized.

Copy link
Member

commented Apr 22, 2016

I think we should to full support on this, i.e if there is config/puma.rb send all of them when we build rack config for puma, so that we don't have more surprising behaviour.

@prathamesh-sonpatki

This comment has been minimized.

Copy link
Member

commented Apr 22, 2016

We can just send -c config/puma.rb if it exists. I will take a stab at this.

@prathamesh-sonpatki

This comment has been minimized.

Copy link
Member

commented Apr 22, 2016

@prathamesh-sonpatki prathamesh-sonpatki self-assigned this Apr 22, 2016

@vipulnsward

This comment has been minimized.

Copy link
Member

commented Apr 22, 2016

@prathamesh-sonpatki that will not work. config/puma.rb will blow away on the rack config option.

➜  puma-demo b rails s -c config/puma.rb
=> Booting Puma
=> Rails 5.0.0.beta3 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
Exiting
/Users/sward/work/experiments/puma-demo/config/puma.rb:8:in `<top (required)>': undefined method `threads' for main:Object (NoMethodError)
    from /Users/sward/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/rack-2.0.0.alpha/lib/rack/builder.rb:42:in `require'
    from /Users/sward/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/rack-2.0.0.alpha/lib/rack/builder.rb:42:in `parse_file'
    from /Users/sward/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/rack-2.0.0.alpha/lib/rack/server.rb:318:in `build_app_and_options_from_config'
    from /Users/sward/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/rack-2.0.0.alpha/lib/rack/server.rb:218:in `app'
    from /Users/sward/work/rails/railties/lib/rails/commands/server.rb:59:in `app'
    from /Users/sward/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/rack-2.0.0.alpha/lib/rack/server.rb:353:in `wrapped_app'
    from /Users/sward/work/rails/railties/lib/rails/commands/server.rb:124:in `log_to_stdout'
    from /Users/sward/work/rails/railties/lib/rails/commands/server.rb:77:in `start'
    from /Users/sward/work/rails/railties/lib/rails/commands/commands_tasks.rb:90:in `block in server'
    from /Users/sward/work/rails/railties/lib/rails/commands/commands_tasks.rb:85:in `tap'
    from /Users/sward/work/rails/railties/lib/rails/commands/commands_tasks.rb:85:in `server'
    from /Users/sward/work/rails/railties/lib/rails/commands/commands_tasks.rb:49:in `run_command!'
    from /Users/sward/work/rails/railties/lib/rails/commands.rb:18:in `<top (required)>'
    from bin/rails:4:in `require'
    from bin/rails:4:in `<main>'

Hence I mentioned we need to parse the config/puma.rb if present and actually pass port to puma via rack option, which is what I had worked on to support.

Again, we need to consider if we need to treat puma as a special case. Either way just passing puma config via -c is a bad option as that will have side effects on rack.

@vipulnsward

This comment has been minimized.

Copy link
Member

commented Apr 22, 2016

btw, another reason we can't just pass config is:

# config/puma.rb
environment ENV.fetch("RAILS_ENV") { "production" }

will always set ENV to production. So we need to select and pass the port.

@prathamesh-sonpatki

This comment has been minimized.

Copy link
Member

commented Apr 22, 2016

I would say we can support PORT from config/puma.rb only in non-dev non-test environment instead of treating as special case.

@schneems

This comment has been minimized.

Copy link
Member

commented Apr 22, 2016

When I made the change in Puma, I was thinking that config/puma.rb would be canonical and take precedence over user supplied values. If that was the case there wouldn't be any problem.

Another thing that could have prevented this situation is if rack handler API supported a values hash and a "default" hash to differentiate between values a user actually supplied versus ones we've chosen. But it's far far too late for that. Maybe we could get that in for Rack 2.0 but I don't think any of us have the time right now.

Right now I think our realistic options for moving forwards would be to either special case the Rails code, or to add some kind of a warning to the Puma code letting you know why we are connecting to a different port.

@prathamesh-sonpatki

This comment has been minimized.

Copy link
Member

commented Apr 22, 2016

Another thing that could have prevented this situation is if rack handler API supported a values hash and a "default" hash to differentiate between values a user actually supplied versus ones we've chosen.

That is a good point.

@BatuhanW

This comment has been minimized.

Copy link

commented Nov 2, 2016

Wow. This is going deeper than I thought.

@jmuheim

This comment has been minimized.

Copy link

commented Jan 11, 2017

This still isn't fixed yet? In Rails 5.0.1, I have this exact behaviour.

Just for the records: using the following code (in config/boot.rb), the port can be changed for the app.

# Change default port of development server, see http://stackoverflow.com/questions/18103316
require 'rails/commands/server'
module DefaultOptions
  def default_options
    super.merge!(Port: 3001)
  end
end
Rails::Server.send(:prepend, DefaultOptions)

jmuheim added a commit to jmuheim/base that referenced this issue Jan 11, 2017

@schneems

This comment has been minimized.

Copy link
Member

commented Jan 12, 2017

This still isn't fixed yet?

If you know how to fix in a sane way, by all means take a stab.

@fidalgo

This comment has been minimized.

Copy link
Contributor

commented Feb 17, 2017

Actually I can set the port via PORT environment variable, but it fails it I use rails s -p 3001.

rails s -p 3001
=> Booting Puma
=> Rails 5.0.1 application starting in development on http://localhost:3001
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.7.0 (ruby 2.3.3-p222), codename: Snowy Sagebrush
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3000
PORT=3001 rails s
=> Booting Puma
=> Rails 5.0.1 application starting in development on http://localhost:3001
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.7.0 (ruby 2.3.3-p222), codename: Snowy Sagebrush
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3001
@jmuheim

This comment has been minimized.

Copy link

commented Feb 17, 2017

It seems to work with the newest Rails version.

The only strange thing is that in the console output, it first states port 3000, then 3001:

=> Booting Puma
=> Rails 5.0.1 application starting in development on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.7.0 (ruby 2.2.6-p396), codename: Snowy Sagebrush
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3001
Use Ctrl-C to stop
@schneems

This comment has been minimized.

Copy link
Member

commented Feb 17, 2017

If you're using rails s this is expected behavior that setting the port in the config/puma.rb while booting via rails s. This is a known bug the work around is to use the puma command to start your server instead. Please subscribe to the issue if you want to hear about it. If you think you're seeing knew behavior please open up a new ticket.

@jmuheim

This comment has been minimized.

Copy link

commented Feb 17, 2017

Thanks for pointing this out.

@detj

This comment has been minimized.

Copy link

commented Feb 19, 2017

When using puma -p 4000, the server still starts with the default port 3000.

rails s -p 4000 doesn't work either. I'm using puma v3.7.0 and rails v4.2.7.1

@y-yagi

This comment has been minimized.

Copy link
Member

commented Feb 19, 2017

When using puma -p 4000, the server still starts with the default port 3000.
rails s -p 4000 doesn't work either.

These are a issue of Puma. Ref: puma/puma#1200

@guilleiguaran

This comment has been minimized.

Copy link
Member

commented Feb 21, 2017

This was fixed with Puma v3.7.1, please upgrade!!

@nateberkopec

This comment has been minimized.

Copy link
Contributor

commented Feb 21, 2017

@guilleiguaran only the issue @detj was referring to was fixed. the original issue remains.

@schneems schneems reopened this Feb 23, 2017

@schneems schneems closed this in 6ac4dab Feb 25, 2017

schneems added a commit that referenced this issue Feb 25, 2017

Merge pull request #28137 from schneems/schneems/fix-default-puma-port
[close #24435] Send user_supplied_options to server
@kirbygit

This comment has been minimized.

Copy link

commented May 16, 2017

So when using vagrant as dev environment and running rails s -b 0.0.0.0 doesn't work. I had to run rails s -p 3000 -b 0.0.0.0 everytime to access localhost:3030

@schneems

This comment has been minimized.

Copy link
Member

commented May 16, 2017

Are you using master?

@kirbygit

This comment has been minimized.

Copy link

commented May 16, 2017

master branch you mean?

@schneems

This comment has been minimized.

Copy link
Member

commented May 16, 2017

Yeah, this should be fixed on puma's master branch. Are you using master and still seeing the issue?

@kirbygit

This comment has been minimized.

Copy link

commented May 16, 2017

Oh it is fixed now, I guess my coteam fixed the issue and I saw it was a bug from the newer puma version to the rails 5.1, he had to use the older version of puma to make it work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.