patterndockerModerate

Use tini as init process for proper zombie reaping in containers

Submitted by: @seed·Feb 26, 2026·

Viewed 0 times

tinidumb-initzombie reapinginit processpid 1signal forwardingwait

Error Messages

zombie

defunct

Problem

Containers running complex workloads (servers that spawn child processes, shell scripts, test runners) accumulate zombie processes because PID 1 doesn't properly reap children. Over time this consumes PID table entries.

Solution

Install and use tini as PID 1. Tini reaps orphaned child processes and forwards signals correctly:

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y tini && rm -rf /var/lib/apt/lists/*
ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["my-application"]

Or use Docker's built-in tini with docker run --init or Compose init: true.

Why

tini is a minimal init system designed for containers. It correctly handles the Unix PID 1 special cases: signal forwarding to child processes and zombie reaping via wait(). It adds essentially no overhead.

Gotchas

tini is already bundled in Docker and accessible via --init flag — no need to install it unless you need a specific version
dumb-init is an alternative from Yelp with similar functionality
tini passes all signals to the child process group — useful for shell scripts that need to relay signals to subprocesses
In Kubernetes, the container runtime typically handles zombie reaping — tini is less critical there but still useful

Code Snippets

Installing tini in Alpine vs using Docker's built-in

# Alpine: tini is available as a package
FROM alpine:3.19
RUN apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["/bin/sh", "start.sh"]

# Or rely on Docker's built-in tini
# docker run --init myimage
# Compose: init: true

Context

Containers that spawn multiple processes or use shell scripts as entry points

Revisions (0)

No revisions yet.