docs: Update website to include SIGHUP, SIGTERM, and SIGINT behaviour (#3140)

* docs: Update website to include SIGHUP, SIGTERM, and SIGINT behaviour

Co-authored-by: Dan Heath <76443935+Dan-Heath@users.noreply.github.com>
pull/3136/merge
Irena Rindos 3 years ago committed by GitHub
parent 55af9f3072
commit b4a8032649
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -106,6 +106,11 @@ description will be read.
are anything specified by Go's [ParseDuration()](https://golang.org/pkg/time/#ParseDuration) method. Only
used when an `ops` listener is set and the Controller is present. Default is 0 seconds.
## Signals
The `SIGHUP` signal causes a controller to reload its configuration file to pick up any updates to the `database url` value. Any other updated values are ignored.
The `SIGTERM` and `SIGINT` signals initiate a graceful shutdown on a controller. A graceful shutdown closes listeners and servers before shutting down the controller.
## KMS Configuration
The controller requires two KMS stanzas for `root` and `worker-auth` purposes:

@ -36,7 +36,7 @@ path to the file.
Boundary serves traffic (API, cluster, and proxy).
Controllers must have at least two listener blocks defined: one marked for
`api` purpose and the other marked for `cluster` purpose.
`api` purpose and the other marked for `cluster` purpose.
Workers will have only one listener, marked for `proxy` purpose.
@ -87,6 +87,16 @@ path to the file.
- [`plugins`](/boundary/docs/configuration/plugins): Configures options for plugins.
## Signals
The `SIGHUP` signal causes worker and controller processes to reload their configuration files to pick up updated values.
~> **Note:** You cannot reload all configuration values using the `SIGHUP` signal. Refer to the configuration pages for
[workers](/boundary/docs/configuration/worker/) and [controllers](/boundary/docs/configuration/controller) for details
on which values can be reloaded on `SIGHUP`.
The `SIGTERM` and `SIGINT` signals cause worker and controller processes to enter graceful shutdown. A graceful shutdown for a controller closes listeners and servers before shutting down the controller. A graceful shutdown for a worker waits for any sessions to drain
before shutting down the worker. Workers in a graceful shutdown state do not receive any new work, including session proxying, from the control plane.
## Example Configurations
For complete example configurations see the sections for

@ -58,8 +58,8 @@ worker {
at which the worker can be reached _by clients for proxying_. This defaults to
the address of the listener marked for `proxy` purpose. This is especially
useful for cloud environments that do not bind a publicly accessible IP to a
NIC on the host directly, such as an Amazon EIP.
NIC on the host directly, such as an Amazon EIP.
This value can reference any of the following:
- a direct address string
- a file on disk (file://) from which an address will be read
@ -85,6 +85,13 @@ worker {
`initial_upstreams`. This is currently only valid for workers using the PKI
registration method and for workers directly connected to HCP Boundary.
## Signals
The `SIGHUP` signal causes a worker to reload its configuration file to pick up any updates for the `initial_upstreams` and `tags` values.
Any other updated values are ignored.
The `SIGTERM` and `SIGINT` signals initiate a graceful shutdown on a worker. The worker waits for any sessions to drain
before shutting down. Workers in a graceful shutdown state do not receive any new work, including session proxying, from the control plane.
## Multi-hop worker capabilities <sup>HCP only</sup>
Multi-hop capabilities, including multi-hop sessions and Vault private access,
is when a session or Vault credential request goes through more than one worker.

Loading…
Cancel
Save