puma 5.0.2-java → 5.2.0-java

data/README.md

@@ -4,7 +4,8 @@
 
 # Puma: A Ruby Web Server Built For Concurrency
 
-[![Actions Build Status](https://github.com/puma/puma/workflows/CI/badge.svg?branch=master)](https://github.com/puma/puma/actions)
+[![Actions MRI](https://github.com/puma/puma/workflows/MRI/badge.svg?branch=master)](https://github.com/puma/puma/actions?query=workflow%3AMRI)
+[![Actions non MRI](https://github.com/puma/puma/workflows/non_MRI/badge.svg?branch=master)](https://github.com/puma/puma/actions?query=workflow%3Anon_MRI)
 [![Code Climate](https://codeclimate.com/github/puma/puma.svg)](https://codeclimate.com/github/puma/puma)
 [![SemVer](https://api.dependabot.com/badges/compatibility_score?dependency-name=puma&package-manager=bundler&version-scheme=semver)](https://dependabot.com/compatibility-score.html?dependency-name=puma&package-manager=bundler&version-scheme=semver)
 [![StackOverflow](https://img.shields.io/badge/stackoverflow-Puma-blue.svg)]( https://stackoverflow.com/questions/tagged/puma )
@@ -63,20 +64,30 @@ You can run your Sinatra application with Puma from the command line like this:
 $ ruby app.rb -s Puma
 ```
 
-Or you can configure your Sinatra application to always use Puma:
+In order to actually configure Puma using a config file, like `puma.rb`, however, you need to use the `puma` executable. To do this, you must add a rackup file to your Sinatra app:
 
 ```ruby
-require 'sinatra'
-configure { set :server, :puma }
+# config.ru
+require './app'
+run Sinatra::Application
+```
+
+You can then start your application using:
+
+```
+$ bundle exec puma
 ```
 
 ## Configuration
 
-Puma provides numerous options. Consult `puma -h` (or `puma --help`) for a full list of CLI options, or see [dsl.rb](https://github.com/puma/puma/blob/master/lib/puma/dsl.rb).
+Puma provides numerous options. Consult `puma -h` (or `puma --help`) for a full list of CLI options, or see `Puma::DSL` or [dsl.rb](https://github.com/puma/puma/blob/master/lib/puma/dsl.rb).
 
 You can also find several configuration examples as part of the
 [test](https://github.com/puma/puma/tree/master/test/config) suite.
 
+For debugging purposes, you can set the environment variable `PUMA_LOG_CONFIG` with a value
+and the loaded configuration will be printed as part of the boot process.
+
 ### Thread Pool
 
 Puma uses a thread pool. You can set the minimum and maximum number of threads that are available in the pool with the `-t` (or `--threads`) flag:
@@ -135,12 +146,12 @@ before_fork do
 end
 ```
 
-Preloading can’t be used with phased restart, since phased restart kills and restarts workers one-by-one, and preload_app copies the code of master into the workers.
+Preloading can’t be used with phased restart, since phased restart kills and restarts workers one-by-one, and `preload_app!` copies the code of master into the workers.
 
 ### Error handling
 
 If puma encounters an error outside of the context of your application, it will respond with a 500 and a simple
-textual error message (see `lowlevel_error` in [this file](https://github.com/puma/puma/blob/master/lib/puma/server.rb)).
+textual error message (see `Puma::Server#lowlevel_error` or [server.rb](https://github.com/puma/puma/blob/master/lib/puma/server.rb)).
 You can specify custom behavior for this scenario. For example, you can report the error to your third-party
 error-tracking service (in this example, [rollbar](https://rollbar.com)):
 
@@ -193,7 +204,7 @@ $ puma -b 'ssl://127.0.0.1:9292?key=path_to_key&cert=path_to_cert&ssl_cipher_fil
 $ puma -b 'ssl://127.0.0.1:9292?keystore=path_to_keystore&keystore-pass=keystore_password&ssl_cipher_list=TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA'
 ```
 
-See https://www.openssl.org/docs/man1.0.2/apps/ciphers.html for cipher filter format and full list of cipher suites.
+See https://www.openssl.org/docs/man1.1.1/man1/ciphers.html for cipher filter format and full list of cipher suites.
 
 Disable TLS v1 with the `no_tlsv1` option:
 
@@ -201,6 +212,23 @@ Disable TLS v1 with the `no_tlsv1` option:
 $ puma -b 'ssl://127.0.0.1:9292?key=path_to_key&cert=path_to_cert&no_tlsv1=true'
 ```
 
+#### Controlling OpenSSL Verification Flags
+
+To enable verification flags offered by OpenSSL, use `verification_flags` (not available for JRuby):
+
+```
+$ puma -b 'ssl://127.0.0.1:9292?key=path_to_key&cert=path_to_cert&verification_flags=PARTIAL_CHAIN'
+```
+
+You can also set multiple verification flags (by separating them with coma):
+
+```
+$ puma -b 'ssl://127.0.0.1:9292?key=path_to_key&cert=path_to_cert&verification_flags=PARTIAL_CHAIN,CRL_CHECK'
+```
+
+List of available flags: `USE_CHECK_TIME`, `CRL_CHECK`, `CRL_CHECK_ALL`, `IGNORE_CRITICAL`, `X509_STRICT`, `ALLOW_PROXY_CERTS`, `POLICY_CHECK`, `EXPLICIT_POLICY`, `INHIBIT_ANY`, `INHIBIT_MAP`, `NOTIFY_POLICY`, `EXTENDED_CRL_SUPPORT`, `USE_DELTAS`, `CHECK_SS_SIGNATURE`, `TRUSTED_FIRST`, `SUITEB_128_LOS_ONLY`, `SUITEB_192_LOS`, `SUITEB_128_LOS`, `PARTIAL_CHAIN`, `NO_ALT_CHAINS`, `NO_CHECK_TIME`
+(see https://www.openssl.org/docs/manmaster/man3/X509_VERIFY_PARAM_set_hostflags.html#VERIFICATION-FLAGS).
+
 ### Control/Status Server
 
 Puma has a built-in status and control app that can be used to query and control Puma.
@@ -209,7 +237,7 @@ Puma has a built-in status and control app that can be used to query and control
 $ puma --control-url tcp://127.0.0.1:9293 --control-token foo
 ```
 
-Puma will start the control server on localhost port 9293. All requests to the control server will need to include control token (in this case, `token=foo`) as a query parameter. This allows for simple authentication. Check out [status.rb](https://github.com/puma/puma/blob/master/lib/puma/app/status.rb) to see what the status app has available.
+Puma will start the control server on localhost port 9293. All requests to the control server will need to include control token (in this case, `token=foo`) as a query parameter. This allows for simple authentication. Check out `Puma::App::Status` or [status.rb](https://github.com/puma/puma/blob/master/lib/puma/app/status.rb) to see what the status app has available.
 
 You can also interact with the control server via `pumactl`. This command will restart Puma:
 
@@ -227,7 +255,7 @@ You can also provide a configuration file with the `-C` (or `--config`) flag:
 $ puma -C /path/to/config
 ```
 
-If no configuration file is specified, Puma will look for a configuration file at `config/puma.rb`. If an environment is specified, either via the `-e` and `--environment` flags, or through the `RACK_ENV` or the `RAILS_ENV` environment variables, Puma looks for configuration at `config/puma/<environment_name>.rb`.
+If no configuration file is specified, Puma will look for a configuration file at `config/puma.rb`. If an environment is specified, either via the `-e` and `--environment` flags, or through the `RACK_ENV` or the `RAILS_ENV` environment variables, Puma first looks for configuration at `config/puma/<environment_name>.rb`, and then falls back to `config/puma.rb`.
 
 If you want to prevent Puma from looking for a configuration file in those locations, provide a dash as the argument to the `-C` (or `--config`) flag:
 
@@ -235,19 +263,19 @@ If you want to prevent Puma from looking for a configuration file in those locat
 $ puma -C "-"
 ```
 
-The other side-effects of setting the environment are whether to show stack traces (in `development` or `test`), and setting RACK_ENV may potentially affect middleware looking for this value to change their behavior. The default puma RACK_ENV value is `development`. You can see all config default values [here](https://github.com/puma/puma/blob/12d1706ddc71b89ed2ee26275e31c788e94ff541/lib/puma/configuration.rb#L170).
+The other side-effects of setting the environment are whether to show stack traces (in `development` or `test`), and setting RACK_ENV may potentially affect middleware looking for this value to change their behavior. The default puma RACK_ENV value is `development`. You can see all config default values in `Puma::Configuration#puma_default_options` or [configuration.rb](https://github.com/puma/puma/blob/61c6213fbab/lib/puma/configuration.rb#L182-L204).
 
-Check out [dsl.rb](https://github.com/puma/puma/blob/master/lib/puma/dsl.rb) to see all available options.
+Check out `Puma::DSL` or [dsl.rb](https://github.com/puma/puma/blob/master/lib/puma/dsl.rb) to see all available options.
 
 ## Restart
 
 Puma includes the ability to restart itself. When available (MRI, Rubinius, JRuby), Puma performs a "hot restart". This is the same functionality available in *Unicorn* and *NGINX* which keep the server sockets open between restarts. This makes sure that no pending requests are dropped while the restart is taking place.
 
-For more, see the [restart documentation](https://github.com/puma/puma/blob/master/docs/restart.md).
+For more, see the [Restart documentation](docs/restart.md).
 
 ## Signals
 
-Puma responds to several signals. A detailed guide to using UNIX signals with Puma can be found in the [signals documentation](https://github.com/puma/puma/blob/master/docs/signals.md).
+Puma responds to several signals. A detailed guide to using UNIX signals with Puma can be found in the [Signals documentation](docs/signals.md).
 
 ## Platform Constraints
 
@@ -255,6 +283,7 @@ Some platforms do not support all Puma features.
 
   * **JRuby**, **Windows**: server sockets are not seamless on restart, they must be closed and reopened. These platforms have no way to pass descriptors into a new process that is exposed to Ruby. Also, cluster mode is not supported due to a lack of fork(2).
   * **Windows**: Cluster mode is not supported due to a lack of fork(2).
+  * **Kubernetes**: The way Kubernetes handles pod shutdowns interacts poorly with server processes implementing graceful shutdown, like Puma. See the [kubernetes section of the documentation](docs/kubernetes.md) for more details.
 
 ## Known Bugs
 
@@ -273,18 +302,21 @@ end
 
 Puma has support for Capistrano with an [external gem](https://github.com/seuros/capistrano-puma).
 
-It is common to use process monitors with Puma. Modern process monitors like systemd or upstart
+It is common to use process monitors with Puma. Modern process monitors like systemd or rc.d
 provide continuous monitoring and restarts for increased
 reliability in production environments:
 
-* [docs/jungle](https://github.com/puma/puma/tree/master/docs/jungle) for rc.d and upstart
-* [docs/systemd](https://github.com/puma/puma/blob/master/docs/systemd.md)
+* [rc.d](docs/jungle/rc.d/README.md)
+* [systemd](docs/systemd.md)
+
+Community guides: 
+
+* [Deploying Puma on OpenBSD using relayd and httpd](https://gist.github.com/anon987654321/4532cf8d6c59c1f43ec8973faa031103)
 
 ## Community Extensions
 
 ### Plugins
 
-* [puma-heroku](https://github.com/puma/puma-heroku) — default Puma configuration for running on Heroku
 * [puma-metrics](https://github.com/harmjanblok/puma-metrics) — export Puma metrics to Prometheus
 * [puma-plugin-statsd](https://github.com/yob/puma-plugin-statsd) — send Puma metrics to statsd
 * [puma-plugin-systemd](https://github.com/sj26/puma-plugin-systemd) — deeper integration with systemd for notify, status and watchdog
@@ -295,9 +327,7 @@ reliability in production environments:
 
 ## Contributing
 
-Find details for contributing in the [contribution guide].
-
-[contribution guide]: https://github.com/puma/puma/blob/master/CONTRIBUTING.md
+Find details for contributing in the [contribution guide](CONTRIBUTING.md).
 
 ## License
 

data/bin/puma-wild

@@ -5,24 +5,18 @@
 
 require 'rubygems'
 
-gems = ARGV.shift
+cli_arg = ARGV.shift
 
 inc = ""
 
-if gems == "-I"
+if cli_arg == "-I"
   inc = ARGV.shift
   $LOAD_PATH.concat inc.split(":")
-  gems = ARGV.shift
-end
-
-gems.split(",").each do |s|
-  name, ver = s.split(":",2)
-  gem name, ver
 end
 
 module Puma; end
 
-Puma.const_set("WILD_ARGS", ["-I", inc, gems])
+Puma.const_set("WILD_ARGS", ["-I", inc])
 
 require 'puma/cli'
 

data/docs/compile_options.md

@@ -0,0 +1,19 @@
+# Compile Options
+
+There are some `cflags` provided to change Puma's default configuration for its C extension.
+
+## Query String, `PUMA_QUERY_STRING_MAX_LENGTH`
+
+By default, the max length of `QUERY_STRING` is `1024 * 10`. But you may want to adjust it to allow accept larger queries in GET requests.
+
+For manual install, pass the `PUMA_QUERY_STRING_MAX_LENGTH` option like this:
+
+```
+gem install puma -- --with-cflags="-D PUMA_QUERY_STRING_MAX_LENGTH=64000"
+```
+
+For Bundler, use its configuration system:
+
+```
+bundle config build.puma "--with-cflags='-D PUMA_QUERY_STRING_MAX_LENGTH=64000'"
+```

data/docs/deployment.md

@@ -1,4 +1,4 @@
-# Deployment engineering for puma
+# Deployment engineering for Puma
 
 Puma is software that is expected to be run in a deployed environment eventually.
 You can certainly use it as your dev server only, but most people look to use
@@ -7,12 +7,11 @@ it in their production deployments as well.
 To that end, this is meant to serve as a foundation of wisdom how to do that
 in a way that increases happiness and decreases downtime.
 
-## Specifying puma
+## Specifying Puma
 
 Most people want to do this by putting `gem "puma"` into their Gemfile, so we'll
 go ahead and assume that. Go add it now... we'll wait.
 
-
 Welcome back!
 
 ## Single vs Cluster mode
@@ -20,7 +19,7 @@ Welcome back!
 Puma was originally conceived as a thread-only webserver, but grew the ability to
 also use processes in version 2.
 
-To run puma in single mode (e.g. for a development environment) you will need to
+To run `puma` in single mode (e.g. for a development environment) you will need to
 set the number of workers to 0, anything above will run in cluster mode.
 
 Here are some rules of thumb for cluster mode:
@@ -30,7 +29,7 @@ Here are some rules of thumb for cluster mode:
 * Use cluster mode and set the number of workers to 1.5x the number of cpu cores
   in the machine, minimum 2.
 * Set the number of threads to desired concurrent requests / number of workers.
-  Puma defaults to 16 and that's a decent number.
+  Puma defaults to 5 and that's a decent number.
 
 #### Migrating from Unicorn
 
@@ -82,7 +81,7 @@ thread to become available.
 
 Daemonization was removed in Puma 5.0. For alternatives, continue reading.
 
-I prefer to not daemonize my servers and use something like `runit` or `upstart` to
+I prefer to not daemonize my servers and use something like `runit` or `systemd` to
 monitor them as child processes. This gives them fast response to crashes and
 makes it easy to figure out what is going on. Additionally, unlike `unicorn`,
 puma does not require daemonization to do zero-downtime restarts.
@@ -92,7 +91,7 @@ task and thus want it to live on past the `cap deploy`. To these people I say:
 You need to be using a process monitor. Nothing is making sure puma stays up in
 this scenario! You're just waiting for something weird to happen, puma to die,
 and to get paged at 3am. Do yourself a favor, at least the process monitoring
-your OS comes with, be it `sysvinit`, `upstart`, or `systemd`. Or branch out
+your OS comes with, be it `sysvinit` or `systemd`. Or branch out
 and use `runit` or hell, even `monit`.
 
 ## Restarting

data/docs/fork_worker.md

@@ -24,6 +24,8 @@ Similar to the `preload_app!` option, the `fork_worker` option allows your appli
 
 ### Limitations
 
+- Not compatible with the `preload_app!` option
+
 - This mode is still very experimental so there may be bugs or edge-cases, particularly around expected behavior of existing hooks. Please open a [bug report](https://github.com/puma/puma/issues/new?template=bug_report.md) if you encounter any issues.
 
 - In order to fork new workers cleanly, worker 0 shuts down its server and stops serving requests so there are no open file descriptors or other kinds of shared global state between processes, and to maximize copy-on-write efficiency across the newly-forked workers. This may temporarily reduce total capacity of the cluster during a phased restart / refork.

data/docs/jungle/README.md

@@ -1,9 +1,5 @@
 # Puma as a service
 
-## Upstart
-
-See `/docs/jungle/upstart` for Ubuntu's upstart scripts.
-
 ## Systemd
 
 See [/docs/systemd](https://github.com/puma/puma/blob/master/docs/systemd.md).

data/docs/jungle/rc.d/puma

@@ -23,7 +23,7 @@ puma_start()
 		rb_ver=$(/usr/local/bin/jq -r ".servers[$i].ruby_version" /usr/local/etc/puma.conf)
 		case $rb_env in
 			"rbenv")
-				su - $user -c "cd $dir && rbenv shell $rb_ver && bundle exec puma -C $dir/config/puma.rb -d"
+				cd $dir && rbenv shell $rb_ver && /usr/sbin/daemon -u $user bundle exec puma -C $dir/config/puma.rb
 				;;
 			*)
 				;;
@@ -48,7 +48,7 @@ puma_restart()
 		rb_ver=$(/usr/local/bin/jq -r ".servers[$i].ruby_version" /usr/local/etc/puma.conf)
 		case $rb_env in
 			"rbenv")
-				su - $user -c "cd $dir && pkill ruby && rbenv shell $ruby_version && bundle exec puma -C $dir/config/puma.rb -d"
+				cd $dir && rbenv shell $rb_ver && /usr/sbin/daemon -u $user bundle exec puma -C $dir/config/puma.rb
 				;;
 			*)
 				;;

data/docs/kubernetes.md

@@ -0,0 +1,66 @@
+# Kubernetes
+
+## Running Puma in Kubernetes
+
+In general running Puma in Kubernetes works as-is, no special configuration is needed beyond what you would write anyway to get a new Kubernetes Deployment going. There is one known interaction between the way Kubernetes handles pod termination and how Puma handles `SIGINT`, where some request might be sent to Puma after it has already entered graceful shutdown mode and is no longer accepting requests. This can lead to dropped requests during rolling deploys. A workaround for this is listed at the end of this article.
+
+## Basic setup
+
+Assuming you already have a running cluster and docker image repository, you can run a simple Puma app with the following example Dockerfile and Deployment specification. These are meant as examples only and are deliberately very minimal to the point of skipping many options that are recommended for running in production, like healthchecks and envvar configuration with ConfigMaps. In general you should check the [Kubernetes documentation](https://kubernetes.io/docs/home/) and [Docker documentation](https://docs.docker.com/) for a more comprehensive overview of the available options.
+
+A basic Dockerfile example: 
+```
+FROM ruby:2.5.1-alpine # can be updated to newer ruby versions
+RUN apk update && apk add build-base # and any other packages you need 
+
+# Only rebuild gem bundle if Gemfile changes
+COPY Gemfile Gemfile.lock ./
+RUN bundle install
+
+# Copy over the rest of the files
+COPY . .
+
+# Open up port and start the service
+EXPOSE 9292
+CMD bundle exec rackup -o 0.0.0.0
+```
+
+A sample `deployment.yaml`:
+```
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-awesome-puma-app
+spec:
+  selector:
+    matchLabels:
+      app: my-awesome-puma-app
+  template:
+    metadata:
+      labels:
+        app: my-awesome-puma-app
+        service: my-awesome-puma-app
+    spec:
+      containers:
+      - name: my-awesome-puma-app
+        image: <your image here>
+        ports:
+        - containerPort: 9292
+``` 
+
+## Graceful shutdown and pod termination
+
+For some high-throughput systems, it is possible that some HTTP requests will return responses with response codes in the 5XX range during a rolling deploy to a new version. This is caused by [the way that Kubernetes terminates a pod during rolling deploys](https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-terminating-with-grace):
+
+1. The replication controller determines a pod should be shut down.
+2. The Pod is set to the “Terminating” State and removed from the endpoints list of all Services, so that it receives no more requests.
+3. The pods pre-stop hook get called. The default for this is to send `SIGTERM` to the process inside the pod.
+4. The pod has up to `terminationGracePeriodSeconds` (default: 30 seconds) to gracefully shut down. Puma will do this (after it receives SIGTERM) by closing down the socket that accepts new requests and finishing any requests already running before exiting the Puma process.
+5. If the pod is still running after `terminationGracePeriodSeconds` has elapsed, the pod receives `SIGKILL` to make sure the process inside it stops. After that, the container exits and all other Kubernetes objects associated with it are cleaned up.
+
+There is a subtle race condition between step 2 and 3: The replication controller does not synchronously remove the pod from the Services AND THEN call the pre-stop hook of the pod, but rather it asynchronously sends "remove this pod from your endpoints" requests to the Services and then immediately proceeds to invoke the pods' pre-stop hook. If the Service controller (typically something like nginx or haproxy) receives this request handles this request "too" late (due to internal lag or network latency between the replication and Service controllers) then it is possible that the Service controller will send one or more requests to a Puma process which has already shut down its listening socket. These requests will then fail with 5XX error codes.
+
+The way Kubernetes works this way, rather than handling step 2 synchronously, is due to the CAP theorem: in a distributed system there is no way to guarantuee that any message will arrive promptly. In particular, waiting for all Service controllers to report back might get stuck for an indefinite time if one of them has already been terminated or if there has been a net split. A way to work around this is to add a sleep to the pre-stop hook of the same time as the `terminationGracePeriodSeconds` time. This will allow the Puma process to keep serving new requests during the entire grace period, although it will no longer receive new requests after all Service controllers have propagated the removal of the pod from their endpoint lists. Then, after `terminationGracePeriodSeconds`, the pod receives `SIGKILL` and closes down. If your process can't handle SIGKILL properly, for example because it needs to release locks in different services, you can also sleep for a shorter period (and/or increase `terminationGracePeriodSeconds`) as long as the time slept is longer than the time that your Service controllers take to propagate the pod removal. The downside of this workaround is that all pods will take at minimum the amount of time slept to shut down and this will increase the time required for your rolling deploy.
+
+More discussions and links to relevant articles can be found in https://github.com/puma/puma/issues/2343.

data/docs/nginx.md

@@ -31,7 +31,7 @@ server {
 
   location / {
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-    proxy_set_header Host $http_host;
+    proxy_set_header Host $host;
 
     # If the file exists as a static file serve it directly without
     # running all the other rewrite tests on it

data/docs/plugins.md

@@ -8,7 +8,7 @@ operations.
 * [tmp\_restart](https://github.com/puma/puma/blob/master/lib/puma/plugin/tmp_restart.rb):
   Restarts the server if the file `tmp/restart.txt` is touched
 * [heroku](https://github.com/puma/puma-heroku/blob/master/lib/puma/plugin/heroku.rb):
-  Packages up the default configuration used by puma on Heroku
+  Packages up the default configuration used by puma on Heroku (being sunset with the release of Puma 5.0)
 
 Plugins are activated in a puma configuration file (such as `config/puma.rb'`)
 by adding `plugin "name"`, such as `plugin "heroku"`.

data/docs/restart.md

@@ -1,41 +1,64 @@
-# Restarts
+Puma provides three distinct kinds of restart operations, each for different use cases. Hot restarts and phased restarts are described here. The third kind of restart operation is called "refork" and is described in the documentation for [`fork_worker`](fork_worker.md).
 
-To perform a restart, there are 3 builtin mechanisms:
+## Hot restart
 
-  * Send the `puma` process the `SIGUSR2` signal (normal restart)
-  * Send the `puma` process the `SIGUSR1` signal (restart in phases (a "rolling restart"), cluster mode only)
-  * Use the status server and issue `/restart`
+To perform a "hot" restart, Puma performs an `exec` operation to start the process up again, so no memory is shared between the old process and the new process. As a result, it is safe to issue a restart any place where you would manually stop Puma and start it again. In particular, it is safe to upgrade Puma itself using a hot restart.
 
-No code is shared between the current and restarted process, so it should be safe to issue a restart any place where you would manually stop Puma and start it again.
+If the new process is unable to load, it will simply exit. You should therefore run Puma under a process monitor when using it in production.
 
-If the new process is unable to load, it will simply exit. You should therefore run Puma under a process monitor (see below) when using it in production.
+### How-to
 
-### Normal vs Hot vs Phased Restart
+Any of the following will cause a Puma server to perform a hot restart: 
 
-A hot restart means that no requests will be lost while deploying your new code, since the server socket is kept open between restarts.
+* Send the `puma` process the `SIGUSR2` signal
+* Issue a `GET` request to the Puma status/control server with the path `/restart`
+* Issue `pumactl restart` (this uses the control server method if available, otherwise sends the `SIGUSR2` signal to the process)
 
-But beware, hot restart does not mean that the incoming requests won’t hang for multiple seconds while your new code has not fully deployed. If you need a zero downtime and zero hanging requests deploy, you must use phased restart.
+### Supported configurations
 
-When you run pumactl phased-restart, Puma kills workers one-by-one, meaning that at least another worker is still available to serve requests, which lead to zero hanging requests (yay!).
+* Works in cluster mode and in single mode
+* Supported on all platforms
 
-But again beware, upgrading an application sometimes involves upgrading the database schema. With phased restart, there may be a moment during the deployment where processes belonging to the previous version and processes belonging to the new version both exist at the same time. Any database schema upgrades you perform must therefore be backwards-compatible with the old application version.
+### Client experience
 
-If you perform a lot of database migrations, you probably should not use phased restart and use a normal/hot restart instead (`pumactl restart`). That way, no code is shared while deploying (in that case, `preload_app!` might help for quicker deployment, see ["Clustered Mode" in the README](../README.md#clustered-mode)).
+* All platforms: for clients with an in-flight request, those clients will be served responses before the connection is closed gracefully. Puma gracefully disconnects any idle HTTP persistent connections before restarting.
+* On MRI or TruffleRuby on Linux and BSD: Clients who connect just before the server restarts may experience increased latency while the server stops and starts again, but their connections will not be closed prematurely.
+* On Windows and on JRuby: Clients who connect just before a restart may experience "connection reset" errors.
 
-**Note**: Hot and phased restarts are only available on MRI, not on JRuby. They are also unavailable on Windows servers.
+### Additional notes
 
-### Release Directory
+* Only one version of the application is running at a time.
+* `on_restart` is invoked just before the server shuts down. This can be used to clean up resources (like long-lived database connections) gracefully. Since Ruby 2.0, it is not typically necessary to explicitly close file descriptors on restart. This is because any file descriptor opened by Ruby will have the `FD_CLOEXEC` flag set, meaning that file descriptors are closed on `exec`. `on_restart` is useful, though, if your application needs to perform any more graceful protocol-specific shutdown procedures before closing connections.
 
-If your symlink releases into a common working directory (i.e., `/current` from Capistrano), Puma won't pick up your new changes when running phased restarts without additional configuration. You should set your working directory within Puma's config to specify the directory it should use. This is a change from earlier versions of Puma (< 2.15) that would infer the directory for you.
+## Phased restart
 
-```ruby
-# config/puma.rb
+Phased restarts replace all running workers in a Puma cluster. This is a useful way to gracefully upgrade the application that Puma is serving. A phased restart works by first killing an old worker, then starting a new worker, waiting until the new worker has successfully started before proceeding to the next worker. This process continues until all workers have been replaced. The master process is not restarted.
 
-directory '/var/www/current'
-```
+### How-to
 
-### Cleanup Code
+Any of the following will cause a Puma server to perform a phased restart: 
 
-Puma isn't able to understand all the resources that your app may use, so it provides a hook in the configuration file you pass to `-C` called `on_restart`. The block passed to `on_restart` will be called, unsurprisingly, just before Puma restarts itself.
+* Send the `puma` process the `SIGUSR1` signal
+* Issue a `GET` request to the Puma status/control server with the path `/phased-restart`
+* Issue `pumactl phased-restart` (this uses the control server method if available, otherwise sends the `SIGUSR1` signal to the process)
 
-You should place code to close global log files, redis connections, etc. in this block so that their file descriptors don't leak into the restarted process. Failure to do so will result in slowly running out of descriptors and eventually obscure crashes as the server is restarted many times.
+### Supported configurations
+
+* Works in cluster mode only
+* To support upgrading the application that Puma is serving, ensure `prune_bundler` is enabled and that `preload_app` is disabled (it is disabled by default).
+* Supported on all platforms where cluster mode is supported
+
+### Client experience
+
+* In-flight requests are always served responses before the connection is closed gracefully
+* Idle persistent connections are gracefully disconnected
+* New connections are not lost, and clients will not experience any increase in latency (as long as the number of configured workers is greater than one)
+
+### Additional notes
+
+* When a phased restart begins, the Puma master process changes its current working directory to the directory specified by the `directory` option. If `directory` is set to symlink, this is automatically re-evaluated, so this mechanism can be used to upgrade the application.
+* On a single server, it's possible that two versions of the application are running concurrently during a phased restart.
+* `on_restart` is not invoked
+* Phased restarts can be slow for Puma clusters with many workers. Hot restarts often complete more quickly, but at the cost of increased latency during the restart.
+* Phased restarts cannot be used to upgrade any gems loaded by the Puma master process, including `puma` itself, anything in `extra_runtime_dependencies`, or dependencies thereof. Upgrading other gems is safe.
+* If you remove the gems from old releases as part of your deployment strategy, there are additional considerations. Do not put any gems into `extra_runtime_dependencies` that have native extensions or have dependencies that have native extensions (one common example is `puma_worker_killer` and its dependency on `ffi`). Workers will fail on boot during a phased restart. The underlying issue is recorded in [an issue on the rubygems project](https://github.com/rubygems/rubygems/issues/4004). Hot restarts are your only option here if you need these dependencies.