Radiator server health and boot up logic
Server startup sequence, recovery mode behavior, and service enable/disable functionality
When Radiator server boots up it will not be able to service requests before the configuration files are read. During this time the server does not respond to any requests. This typically lasts less than a second.
After the configuration has been read the server can start serving requests. It is possible that the configuration contains errors or points to invalid (expired) certificates. In this case the service enters 'recovery mode' resulting in the following behaviour:
- HTTP UI continues working, assuming the error in configuration makes it fail too
- HTTP API continues working, returning not healthy when prompted through the api
- All TCP based services will close connection immediately and no data will be transmitted
- All UDP based services will not respond to packets received
Example API output
The health api does not need any authentication so it is easy to test. Command to run:
curl "http://localhost:8080/api/v1/health" | jq .
And resulting output:
{
"ok": false,
"code": "RECOVERY_MODE",
"authenticated": false,
"message": "Server running in recovery mode due to configuration file error"
}
Please rely on the "ok" field for status. The other fields are subject to change.
Disabling and Enabling services
The UI contains 'Services enabled' checkbox. This can be used to disable immediate responses to any new requests. It does not stop container endpoints from responding to health checks.
There is also an API end point for enabling and disabling services /api/v1/application/control
Shutdown
Once shutdown is initiated (kill signal for example) the server stops responding to all external requests. With the exception of /live endpoint.