This way, when you send `SIGINT` to a running a server, when running via
`rails s`, a graceful shutdown/stop will be performed.
Before this, not trapping `SIGINT` would mean that either `Rails::Server#start`
or `::Rack::Server#start` would be trapping `SIGINT` and exiting the process.
when restarting a symlinked server the BUNDLE_GEMFILE env var
will point to the old releases Gemfile ... which results in running gems that
do not belong to the current release
- prevents apps from forever poisoning the ENV by doing bad things (something overrides PATH/HOME etc)
- allows use of Dotenv to load new ENV settings from disk (they do not override)
Test:
```
puts "THIS SHOULD CHANGE #{ENV["TEST"] ||= rand.to_s}"
```
then restart the server
Ruby 2.0 changed this behaviour so fds are closed by default during an
exec. If using socket activation from systemd however this closes the
fds before they can be activated.
Adding this options seems to fix things.
The "default" thread in the handler was interpreted as canonical and took precedence over the `config/puma.rb` file. Fixed by using defaults already present in `configuration.rb` which is used by the Launcher.
We only advertise `Puma.cli_config` when puma is set via the cli. Not sure why but if `cli.rb` hasn't been loaded then we don't need to run that code.
Moving requires to Launcher so it can be called as a standalone file (otherwise we get require errors).
The "cli_options" aren't always going to be from a CLI, also this makes it explicit that they are an input, and therefore not cannonical. Switch to `launcher_args` because if I was writing this in Ruby 2.1 they would be kwargs, and the "options" word is confusing since there's enough arguments.
Don't store @cli_options in Launcher (there are too many "options" hashes and their roles are confusing, let's make them more obvious, the arguments passed to cli_options are parsed and turned into @options).
This is a WIP. This was the minimum I could do to get all tests to pass without changing any tests. Eventually I think we want all high level process controls to come from launcher, I also think we want another separate object that gets passed to Runner/Single/Cluster that will maintain a relationship with the Launcher. We could use this as the object that also gets exposed to the app like the Embeddable class we talked about earlier.
Moving forwards i'm planning to port out the CLI tests to only test that they are parsing the correct config and launching servers. I'll port all low level unit tests over to the launcher. Making this change we could either keep all the public methods in CLI that delegate to `@launcher`, I'm guessing not many people are using the internals of CLI and we can take them out. It's your call though.
Wanted to kick this over the fence and see if you had any strong reactions or feelings about this approach.
