Both settings default to
0: no signal is sent and the sandbox is deleted or put on standby right away. A value above the maximum or below 0 is rejected with a 400 error.
Configure the grace periods
Set the grace periods when you create the sandbox:spec.runtime of the Create sandbox API. They are read when the sandbox is created, so changing them requires a new sandbox.
Handle deletion
When a sandbox with a termination grace period is deleted, its processes receiveSIGTERM. The sandbox is deleted as soon as they exit, or when the grace period ends, whichever comes first. A sandbox in standby is resumed first so that it can receive the signal, and the time to resume counts against the grace period.
Handle standby
When a sandbox with a standby grace period goes idle, its processes receiveSIGUSR2. The sandbox keeps running across the standby: use the signal to flush buffers, write a checkpoint or close outbound connections.
The sandbox goes on standby when your code says it is done, or when the grace period ends, whichever comes first. To say it is done, write done to the file at $BLAXEL_STANDBY_READY_FILE. Write it even if the preparation fails, otherwise the sandbox waits for the full grace period.
If the sandbox becomes active again during the grace period, the standby is cancelled: a new request, a new connection or a keep-alive cancels it. The next time the sandbox goes idle, it receives SIGUSR2 again.
Which processes receive the signals
The sandbox API receives both signals and passes them on to the processes it started: the--command of the image and the processes started through the process API. On deletion, it waits for all of them to exit before it shuts down.
If the entrypoint of your image is your own program rather than the sandbox API, it receives both signals directly.
Standby mode
Learn how sandboxes go on standby and resume.
Sandbox keep-alive
Keep a sandbox awake while a process runs.