Skip to main content
< All Topics

Systemd vs. Docker Init

Posted
Updated
Author -Rajkumar Aute
Views106
Systemd vs. Docker Init: Who is the Boss of Your Container?

In the world of Linux, someone has to be the boss. That boss is the Process ID 1 (PID 1). It starts first and manages everything else. To understand how PID 1 works across different environments, it helps to use an analogy:

  • Systemd is like a Hotel Manager: They manage the reception, housekeeping, the kitchen, security, and electricity all at once. It’s heavy, powerful, and complex because running a whole hotel (an Operating System) is hard work.
  • Docker Init (Tini) is like a Private Bodyguard: Their only job is to protect one specific VIP guest (your application). They don’t care about the kitchen or the laundry; they just ensure the guest is safe and leaves the building (shuts down) properly.

Quick Reference

  • Systemd is a “Suite of tools” for a full OS; it does too much for a simple container.
  • Docker Init solves the “Zombie Process” problem where dead processes eat up memory.
  • Signal Handling is the main reason we need an init process; otherwise, your app won’t stop when you tell it to.
FeatureSystemdDocker Init (Tini/Dumb-init)
RoleFull OS Service ManagerLightweight Process Supervisor
ComplexityHigh (Heavyweight)Low (Lightweight)
PID 1 CapabilityNative, full-featuredMinimal, focused on signals
Zombie ReapingYes, handles complex treesYes, handles direct children
Best Use CaseVirtual Machines (VMs), Bare MetalContainers (Docker, Kubernetes)
Signal HandlingComplexPassthrough (sends signals to app)

The Heavyweight: Systemd

In modern Linux distributions (Ubuntu, CentOS, RHEL, Amazon Linux), the very first process that the Linux kernel starts after booting is systemd. It is assigned Process ID (PID) 1.

Every other process on the system including your SSH daemon, your container runtime, and your Kubernetes worker node components is ultimately a child of systemd.

Systemd is the standard initialization system for most Linux distributions (like Ubuntu, CentOS, and Debian).

  • Role: It acts as PID 1 on virtual machines and bare-metal servers. It boots the user space, manages services, handles logging (journald), mounts filesystems, and manages hardware changes.
  • Complexity: It is designed to manage an entire operating system with multiple background services running simultaneously.

Containers are designed to run a single application, not a full OS. Running Systemd inside a container is usually considered an anti-pattern because it adds unnecessary overhead and complexity.

Why Containers Still Need a Boss

Even though a container runs a single app, it still needs a PID 1 to handle two specific kernel responsibilities:

  1. Reaping Zombie Processes: When a process dies, it becomes a “zombie” until its parent acknowledges its death. If the application inside the container doesn’t handle this (and most don’t), the container fills up with zombie processes. Note: Zombies don’t eat up RAM; they consume entries in the kernel’s Process ID (PID) table. If the PID table fills up, your system cannot spawn any new processes.
  2. Signal Handling: When you run docker stop, a SIGTERM signal is sent. A proper init process ensures this signal is passed to the application so it can save data, close connections, and shut down gracefully.

Why systemd Replaced SysV Init

Historically, Linux booted using SysV init scripts a sequential series of bash scripts. If script A took 10 seconds to start, script B had to wait.

systemd revolutionized Linux initialization by introducing:

  • Aggressive Parallelization: It starts services simultaneously, drastically reducing boot times.
  • Dependency Management: It understands that the web server needs the network to be up first, and orders the startup accordingly.
  • Standardized Logging: It introduced journald, centralizing all service logs into a binary format.
  • Cgroup Integration: It natively manages Cgroups (which we covered in our first module) to track processes and apply resource limits.

Core Concepts: Units and Targets

systemd doesn’t just manage services; it manages “Units.” A Unit is any resource that systemd knows how to operate on.

Common Unit Types

  • .service: A system service or daemon (e.g., docker.service, kubelet.service).
  • .socket: A network socket or IPC socket. systemd can listen on a socket and only start the associated .service when traffic arrives (socket activation).
  • .target: A logical grouping of units, used to bring the system to a specific state. (e.g., multi-user.target is the standard server state without a GUI).
  • .timer: A systemd managed timer that triggers other units (the modern replacement for cron jobs).
  • .mount: Controls mounting of file systems.

–

The Lightweight: Docker Init (Tini)

In the previous section, we established that systemd acts as PID 1 on a standard Linux host, managing services, handling signals, and reaping dead processes.

However, running systemd inside a container violates the core philosophy of containerization (which is “one concern per container”). It is far too heavy, requires too many privileges, and expands the attack surface.

Instead, when you run a Python script, a Node app, or a Java server in a container, that application typically becomes PID 1. This creates a massive, often invisible issue known as The PID 1 Problem.

Tini (Docker Init): Docker includes a tiny init process (often tini) that can act as PID 1. It does nothing but forward signals and reap zombies, keeping the container lightweight and strictly focused on the application.

The PID 1 Problem Explained

When an application runs as PID 1 inside a container’s isolated PID namespace, it inherits two massive responsibilities from the Linux kernel that standard applications are simply not programmed to handle.

Responsibility A: Zombie Reaping

In Linux, when a process finishes its task and dies, it doesn’t disappear immediately. It becomes a “zombie” process. It waits in the process table for its parent process to acknowledge its death (a process called “reaping,” using the waitpid() system call).

  • The Orphan Issue: If a parent process dies before its child, the child becomes an “orphan.” The Linux kernel automatically assigns all orphaned processes to PID 1.
  • The Crash: If your Node.js app is PID 1, and it adopts an orphan, it doesn’t know how to reap it. Over time, these zombie processes accumulate, exhausting the host’s PID space, eventually crashing the container or the underlying node.

Responsibility B: Signal Handling

When you issue a docker stop or when Kubernetes scales down a Pod, the container runtime sends a SIGTERM (Termination Signal) to PID 1.

  • The Graceful Shutdown Failure: The Linux kernel treats PID 1 specially; it will not apply default signal handlers to it. If your application hasn’t explicitly written code to catch SIGTERM, it will ignore the signal entirely.
  • The Force Kill: The runtime waits (default 10 seconds in Docker, 30 seconds in Kubernetes) and then sends a SIGKILL, immediately terminating the application. This causes dropped database connections, interrupted transactions, and corrupted files.

The Solution: Enter tini

To solve this without bloating the container, Docker incorporated a tiny, ultra-lightweight init process called tini (developed by Krallin).

tini is a C program that does exactly two things, and does them perfectly:

  1. It registers signal handlers: It catches signals like SIGTERM from the container runtime and immediately passes them down to your actual application.
  2. It reaps zombies: It continuously loops, waiting for adopted child processes to die, and immediately reaps them, keeping the process table clean.

Why This Matters for Kubernetes

In a Kubernetes environment (like AWS EKS), Pod termination lifecycle is critical.

If a Pod’s PID 1 ignores SIGTERM, the Pod gets stuck in a Terminating state for its entire terminationGracePeriodSeconds (default 30s) before being forcibly killed. If you are doing rolling updates of a massive microservice, a 30-second delay per Pod can turn a 2-minute deployment into a 45-minute outage.

Using tini ensures that when Kubelet sends the SIGTERM, your application receives it, gracefully closes its database connections, finishes its current HTTP requests, and exits cleanly in milliseconds.

DevSecOps Architect

At an architectural level, using Systemd in Docker breaks the “One Container, One Service” philosophy. Systemd requires high privileges (often CAP_SYS_ADMIN), which is a security risk.

  • Signal Propagation: Tini registers signal handlers for standard signals (SIGTERM, SIGINT) and forwards them to the child process group. This ensures that if you kill the container, your database or web server gets the message and closes connections safely.
  • Orchestration Impact: In Kubernetes, graceful termination is critical. If your container doesn’t handle signals (because it lacks a proper Init), K8s will wait for the terminationGracePeriodSeconds (usually 30s) and then forcefully kill the pod. This slows down deployments and can corrupt data.

  • Dumb-init: Similar to Tini, developed by Yelp.
  • S6 Overlay: If you really need multiple processes in one container (anti-pattern but sometimes necessary), use S6 instead of Systemd.

 Key Characteristics

  • Minimal Footprint: Docker Init binaries are typically extremely small (KB size).
  • Transparency: You shouldn’t even know it’s there; it just makes standard commands work.

Use Case

  • Java/Node/Python Apps: Interpreters often don’t handle PID 1 responsibilities well. Always use --init or Tini.
  • CI/CD Agents: Jenkins agents running in Docker often spawn many child processes (git, build tools) that need reaping.

Benefits

  • Stability: Prevents “Zombie Apocalypse” inside containers.
  • Speed: Faster container shutdowns (no waiting 10s for timeout).
  • Security: Avoids giving containers dangerous privileges required by Systemd.

Limitations

  • Systemd Dependencies: Legacy applications that expect Systemd (e.g., they try to run systemctl start apache2) will fail in standard Docker containers.
  • Logging: Systemd handles logging via Journald. In Docker Init, logs must go to stdout/stderr for Docker to capture them.

Common Issues & Solutions

ProblemSolution
Container takes 10s to stopThe app isn’t receiving SIGTERM. Use docker run --init. Also, check your Dockerfile: use the exec form (ENTRYPOINT ["npm", "start"]) rather than the shell form (ENTRYPOINT npm start) to prevent the shell from blocking signals.
“Defunct” processes in topZombies are not being reaped. Add Tini to your Dockerfile or use the --init flag.
“System has not been booted with systemd”You are trying to use systemctl inside a container. Rewrite the startup script to call the binary directly (e.g., httpd -DFOREGROUND).

Quiz Linux Systemd vs. Docker Init

Contents
Scroll to Top