Container init: signals, children, and the lifetime of PID 1

The first process created in a new PID namespace receives PID 1 there, while it can have a different PID in an ancestor namespace. Entering a PID namespace with the relevant interfaces affects subsequently created children rather than renumbering an already running process in place. Mounting a suitable proc filesystem also matters to the process view: a PID namespace and an inherited proc mount are separate configuration choices. Record which namespace each observed identifier belongs to before interpreting a process listing.

When a process exits, orphaned descendants are adopted by the appropriate surviving subreaper or namespace init according to Linux's parentage rules. A zombie is an exited child whose status has not yet been collected, not a running task still doing useful computation. The responsible parent uses wait-family operations to collect eligible children. One SIGCHLD notification is not a reliable one-child counter because ordinary signals can coalesce. A supervisor must drain available wait results correctly, including interrupted calls and no-more-ready-child conditions.

Namespace init has special signal handling rules. Other members cannot simply rely on an unhandled default-action termination signal killing PID 1. An init or supervisor should deliberately install appropriate handlers and define how a requested stop reaches the actual application and its children. A shell that starts a child without replacing itself may remain the signal target. Using exec for a simple single-process entrypoint changes that relationship, but does not automatically teach the application to reap orphaned children or supervise a process tree.

An ancestor PID namespace can forcibly deliver SIGKILL or SIGSTOP to the child namespace's init subject to the documented permission rules. If namespace init dies, Linux kills the remaining processes in that PID namespace; keeping a namespace file descriptor does not make its dead init reusable. This is different from a single worker dying while the supervisor remains alive. A graceful stop policy should allow necessary cleanup before escalation, then collect statuses and report the intended result rather than treating every disappearance as successful completion.

A useful fixture launches a child that forks a short-lived grandchild, then exercises ordinary exit and termination while observing parentage and wait results. Check that intended workers receive the stop request, no unexpected child remains running, and collection does not leave an accumulating zombie count. Include an application that ignores its first stop request to test escalation. A readiness endpoint returning success proves none of those lifecycle properties. Match the runtime's actual signal target and process-group behavior rather than assuming every descendant receives every signal.

The queue lab offers a limited collection-pressure analogy. Reset, explicitly set arrival four and service three, predict growth from four pending statuses, then Play or Step. For a separate drain experiment Reset and explicitly set arrival zero and service two before predicting and playing. A rate edit retains elapsed time and recomputes from the initial four items. This continuous fluid model contains no PIDs, SIGCHLD, wait syscall, process groups, or init-death behavior; use the actual fixture to test those mechanisms.