Comparison
EntrypointvsPID 1 problem
Entrypoint
the container starts a shell that starts your process, so signals stop at the shell and nothing ever shuts down cleanly.
The command the runtime executes as the container's first process, plus the default arguments an orchestrator can override. The distinction between the fixed part and the overridable part is where most confusion lives, and wrapping it in a shell form quietly inserts an extra process that becomes PID 1. Getting it wrong shows up as containers that ignore SIGTERM and are killed by the grace-period timeout on every deployment.
Full entry →PID 1 problem
the shutdown signal is delivered and ignored, and every rollout takes exactly thirty seconds per pod before something kills it.
The consequence of a container's first process being PID 1: the kernel applies no default signal handlers to it, and it is responsible for reaping orphaned children. An application never written to be an init system therefore ignores SIGTERM and leaks zombie processes. The fixes are to handle signals properly in the application, use the runtime's small init helper, or exec the real process so it becomes PID 1 itself.
Full entry →