The direct answer
Review the effective launch topology before relying on a container stop plan. For this single native-worker profile, independently establish that the intended executable is the container’s main process, then match its supported handler to the effective initial signal and grace policy. A stop request alone supplies no evidence of graceful cleanup or a completed AI job.
A worker label does not identify the first signal recipient
A report worker has a familiar image name and a documented shutdown handler. An operator proposes stopping its container before reviewing a draft artifact. The missing question is which executable the effective launch actually made the main process. An image caption does not answer that question, and a handler in a child program does not establish a delivery path to it.
This original worksheet selects one trusted native Linux worker running directly as the main process. It excludes starter scripts, supervisors, spawned children, multiple services, orchestrator shutdown hooks and alternative signal APIs. The narrow positive is an eligible shutdown plan for that owned process, with actual execution and application outcomes still requiring separate evidence.
Separate the documented topology from the stop policy
The Dockerfile reference distinguishes exec and shell forms. An unreplaced shell-form ENTRYPOINT starts beneath a command shell that does not pass signals; its executable is not PID 1. The reference also shows explicit replacement changing this topology, so this is not a prohibition on every shell-form arrangement. Runtime entrypoint overrides matter. STOPSIGNAL supplies an image default that container configuration can override.
The stop reference describes signaling the main process, followed by SIGKILL if it has not exited when a finite timeout expires. The initial signal and timeout are configurable; absent a configured signal, SIGTERM is the default. An indefinite-wait setting also exists. These maintained pages establish no installed Engine version or actual worker behavior here.
Keep those facts distinct from this worksheet’s stricter direct-worker policy. It supplies neither a shell replacement recipe nor a signal-forwarding implementation. A launch arrangement outside the selected profile needs its own complete review.
Write the recipient and outcome ledger before admission
| Field | Question to establish independently | Hold when unknown |
|---|---|---|
| Owned container instance | Which admitted instance and lifetime does this plan concern? | A name or old inspection record is insufficient |
| Effective launch | Which image entrypoint, command and effective overrides apply? | Do not substitute image defaults for actual configuration |
| Actual main executable | Is the intended native worker itself the main process? | A launcher with the worker as a child is outside this profile |
| Signal contract | Which effective initial signal matches the worker’s supported handler? | A handler description alone establishes no actual association |
| Grace and escalation | What owned waiting policy applies, including forced termination? | Do not promise cleanup from a waiting interval |
| Independent outcome | What establishes exit, artifact disposition and job state? | Leave each unresolved outcome visibly unknown |
For a paper positive, call the container C-A and the independently admitted native worker W-A. Stipulate complete evidence that W-A is C-A’s actual main executable, with no launcher or children, and that its supported handler matches the effective initial signal. Also stipulate an owned grace policy, supported observation path, appropriate resource access and current operation rights. Only then mark the plan eligible for that specific instance.
These are teaching stipulations, not observations. No container, process, signal, handler, timer or stop operation was constructed or run. Every actual prerequisite remains unknown and unimplemented in this article, so the example cannot authorize a real shutdown.
Make the contrast a changed recipient, not a changed label
Now change only the paper launch: C-B retains a shell as its main process, while W-B runs below it, without explicit replacement or an independently established forwarding mechanism. A stop plan justified by W-B’s handler has lost its recipient association. The proposed disposition is to reject this direct-worker profile, not to invent a wrapper repair or infer that every possible shell arrangement fails.
An exec-form declaration is also insufficient when the named executable is actually a launcher that creates another worker. The receipt asks for the intended native worker itself. Conversely, a reviewed image can be displaced by an effective runtime override. Keep launch evidence bound to the current instance instead of carrying a familiar image’s conclusion across changed configuration.
The same discipline applies after a stop is requested. A submitted operation, an observed process exit and a correctly committed draft are different entries. Even established exit cannot answer whether interrupted output is complete, whether another copy exists, or whether an external effect already occurred.
Review eight separate shutdown dispositions
| Condition | Proposed disposition |
|---|---|
| All stipulated direct-worker prerequisites are independently established for C-A | Conditionally admit only its owned shutdown plan |
| An unreplaced shell remains main and the worker is a child without established forwarding | Reject this direct-worker recipient claim |
| Exec-form entrypoint names a launcher that spawns the intended worker | Outside the selected single-process profile |
| Reviewed image defaults exist but effective runtime overrides are unknown | Hold actual launch and recipient association |
| Effective signal differs from the supported handler contract | Hold a graceful-shutdown claim |
| Finite grace expires and forced termination follows | Do not infer graceful cleanup or artifact commitment |
| Stop request exists but process outcome is unknown | Keep exit and job state unresolved |
| Exit is established but artifact completeness or current rights are unknown | Withhold application-result release independently |
Keep process control separate from application completion
Before a future implementation relies on this plan, it needs complete effective configuration, instance lifetime, actual executable topology, supported native handler semantics, resource ownership, outcome observation and current rights. A matching command string is not enough. This worksheet establishes no Unix credential-to-signal permission equivalence and changes no existing file, shell or descriptor-admission contract.
Choose grace and recovery policy from the actual workload’s supported behavior; this article recommends no production duration. Preserve incomplete artifacts as unresolved rather than publishing them because a container disappeared. Any job retry, external effect or result release still follows its separate evidence and authorization contract.
Boundary is prelaunch and does not ship this container-shutdown controller. No Dockerfile, image, container, process, signal, shell wrapper, API/model or runtime fixture was created or executed. Its synthetic policy checks verify different behavior; they provide no shutdown measurements.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.