Bind to (systemd) activated sockets, regardless of configured binds.
Systemd can present sockets as file descriptors that are already opened.
By default Puma will use these but only if it was explicitly told to bind
to the socket. If not, it will close the activated sockets. This means
all configuration is duplicated.
Binds can contain additional configuration, but only SSL config is really
relevant since the unix and TCP socket options are ignored.
This means there is a lot of duplicated configuration for no additional
value in most setups. This option tells the launcher to bind to all
activated sockets, regardless of existing binds.
The special value 'only' can be passed. If systemd activated sockets are
detected, all other binds are cleared. When they aren't detected, the
regular binds will be used.
* Adds systemd notification support
* Improve systemd notification support
This takes the work by @acmh and improves on it. This is done by
squashing all commits and rebasing it. Then the following changes were
made:
* Dropped SD_NOTIFY env var. There is aleady the NOTIFY_SOCKET env var
presented by systemd and is redundant.
* Move code is pushed in Puma::Systemd
* on_reload now emits RELOADING=1 notification to systemd
* Drop lower bound check on usec. Systemd can only be configured in
seconds and it's hard to misconfigure. The actual code should be safe.
* Clean up integration tests and skip on JRuby
Co-authored-by: Artur Montenegro <artur.montenegro@tempest.com.br>
Any wrapper scripts which `exec`, or other indirections in
`ExecStart`, may result in activated socket file descriptors being closed
before they reach the puma master process. For example, if using `bundle exec`,
pass the `--keep-file-descriptors` flag.
`bundle exec` can be avoided by using a `puma` executable generated by
`bundle binstubs puma`.
This commit also remove a couple of trailing whitespaces
Ref: #1499
With previous configuration `pumactl restart` would't work. It would stop puma instead of restarting if it was started by systemd before. This also occurs when capistrano restarts puma after deploy.
* More docs/systemd refinements
* Section renamed Alternative Forking Configuration with explanation
given for when to use this.
* capistrano3-puma in sub-section with consolidated dry-run shell
commands
* Section Service Configuration contrasts and references Forking
section
* Streamline config samples and highlight using ini format
* More intro to docs/systemd, alt forking section
* Add docs/systemd link to tools/jungle/README, for parity
* Add systemd, alt-forking Always and WantedBy
* Add another link to systemd from README, capistrano section
* minor typo
I found that the configuration proposed doesn't fit very well when Puma is daemonized, that is a common situation when Capistrano is used for deployment. I added my configuration which seems to work pretty well together with the default capistrano3-puma gem settings.
Jacob Herrington