PID 1 and Signal Handling

Suppose a backend service is running inside a container. During deployment, the platform asks the container to stop and gives the service time to finish its in-flight requests.

But no shutdown message appears. After the grace period, the container is forcibly killed.

A common cause is this process tree:

The shell is PID 1, while the actual server runs as its child. When the container runtime sends a stop signal, it targets PID 1. That signal does not automatically propagate to the server.

This is why PID 1 matters inside a container. It also acts as the init process for the container’s PID namespace, adopting orphaned processes and reaping terminated children.

A container’s PID 1 is not just the first process to start. It receives lifecycle signals and defines the lifetime of the container.

Running the application directly as PID 1, or using a proper init process, helps ensure signals and child processes are handled correctly.

This chapter explains PID 1 semantics inside a PID namespace, follows container stop signals, exposes the shell-form startup trap, and examines exec, signal handling, child reaping, minimal init processes, process groups, and shutdown diagnosis.