Add a bit more context about SIGTERM and PID 1 (#11036)

This commit is contained in:
Zanie Blue 2025-01-29 08:21:47 -06:00 committed by GitHub
parent 7633f1db83
commit e7fc05e460
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 6 additions and 1 deletions

View File

@ -29,7 +29,12 @@ pub(crate) async fn run_to_completion(mut handle: Child) -> anyhow::Result<ExitS
// SIGTERM in shells. It is _possible_ to have a parent process that sends a SIGTERM to the
// process group; for example, `tini` supports this via a `-g` option. In this case, it's
// possible that uv will improperly send a second SIGTERM to the child process. However,
// this seems preferable to not forwarding it in the first place.
// this seems preferable to not forwarding it in the first place. In the Docker case, if `uv`
// is invoked directly (instead of via an init system), it's PID 1 which has a special-cased
// default signal handler for SIGTERM by default. Generally, if a process receives a SIGTERM and
// does not have a SIGTERM handler, it is terminated. However, if PID 1 receives a SIGTERM, it
// is not terminated. In this context, it is essential for uv to forward the SIGTERM to the
// child process or the process will not be killable.
#[cfg(unix)]
let status = {
use std::ops::Deref;