In this lesson, you will learn how the standard shell process management techniques you’ve already mastered—like signal propagation and exit status interpretation—map directly to the lifecycle of processes inside a container.
The PID 1 Responsibility
In a standard Linux shell environment, when you run a command, your shell (like bash) acts as the parent process. It spawns the command, waits for it to finish, and collects its exit status. Containers operate under the exact same principle, but with a critical twist: the "main" process inside the container is assigned PID 1.
In Linux, PID 1 is special. It is responsible for "reaping" orphaned processes (adopting processes whose parents have died) and handling signals like SIGTERM. If you run a simple script as your container's entry point, it often fails to act as a proper init system, meaning it won't forward signals to its children or clean up zombie processes. This is why "Managing Process Lifetimes" in containers is essentially the practice of ensuring your entry point process behaves like a well-behaved shell parent.
Bridging Shell and Containers
When you use a command like docker run, you are essentially orchestrating a process pipeline that is isolated from the host. If your containerized process spawns sub-processes—common in complex lifecycle dependencies—you must ensure those children receive the signals sent to the container.
Consider this common trap: if your entry point is a shell script, the shell often swallows SIGTERM signals. To fix this, we use the exec command to replace the shell process with our application:
#!/bin/sh
# Instead of just running the app, we use 'exec'
# This replaces the shell PID 1 with the application process
exec /usr/bin/my-app
By using exec, the application becomes PID 1. It then directly receives the signals sent by the container runtime, allowing it to shut down gracefully and report its exit status correctly, just as you learned when interpreting process exit statuses in earlier lessons.
Key Takeaway: A container’s lifecycle is defined by its PID 1 process; to manage it effectively, ensure your entry point uses exec to properly handle signal propagation and process reaping.