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

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.

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 it's not- https://gist.github.com/vipulnsward/f3e1a3ae26f5160d9de5f6e2837ce13e
App created via master today.

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

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?

@schneems so the above would work because of

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

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

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

WDYT?

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.

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

r? @prathamesh-sonpatki

@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.

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.

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

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.

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.

Wow. This is going deeper than I thought.

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)

This still isn't fixed yet?

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

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

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

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.

Thanks for pointing this out.

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

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

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

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

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

Are you using master?

master branch you mean?

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

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.