Here’s a comprehensive, practical, and explanatory tutorial on the topic of PID 1 in physical servers, virtual machines, and containers, including why PID 1 is special in containers, how it relates to the Linux process tree, and how you can experiment with it using Ubuntu containers.

Understanding PID 1: Physical Servers, Virtual Machines, and Containers

Introduction

Every modern computing environment—whether it’s a physical server, a virtual machine, or a container—relies on a process management system. At the core of this system is a very special process known as PID 1 (Process ID 1). Understanding PID 1’s role and behavior is essential for anyone working with Linux systems, especially in the age of containers and cloud-native applications.

This tutorial covers:

• The meaning and role of PID 1 in different environments
• Why PID 1 is unique and important
• How PID 1 differs between physical/virtual servers and containers
• Practical hands-on: Experimenting with PID 1 in an Ubuntu container
• Best practices and runtime considerations

What is PID 1?

In Linux and UNIX-like operating systems, every process is assigned a unique process ID (PID). PID 1 is always reserved for the very first process that the kernel starts during boot. This process is special:

• It acts as the init process—the ancestor of all other processes.
• It is responsible for reaping orphaned child processes (adopting and cleaning up “zombie” processes).
• If PID 1 exits, the system will typically halt or panic (in traditional servers/VMs).

PID 1 in Different Environments

1. Physical Server

• Boot Process: When a physical server boots, the kernel loads into memory and the very first user-space program it starts is init (historically /sbin/init, now often systemd or another init system).
• PID 1 Role: The init system is always PID 1.
• Responsibilities: It starts all other system services, manages the system lifecycle, and handles orphaned processes.

2. Virtual Machine

• Boot Process: When a VM starts, it simulates a physical machine. The guest OS kernel starts, and again, the first user-space process is init/systemd with PID 1.
• PID 1 Role: Same as a physical server—runs the OS service manager.
• Responsibilities: Identical to physical servers.

3. Container

• Boot Process: When a container starts, it does not boot a full OS. Instead, it starts a process specified in the container image (like /bin/bash, nginx, or your app) directly as PID 1 in a new namespace.
• PID 1 Role: Whatever command you specify in your Dockerfile or docker run becomes PID 1 inside the container!
• Responsibilities:
  • Must reap zombie processes (or else container leaks processes).
  • If it exits, the entire container stops.
  • Can be any executable (unlike physical/VM, where it must be init/systemd).

Why is PID 1 Special in Containers?

• Process Reaping: Only PID 1 receives “orphaned” (zombie) child processes. If PID 1 does not handle them, your container can get filled with zombies, causing resource leaks.
• Signal Handling: PID 1 in Linux does not handle signals like other processes. For example, by default it ignores SIGTERM and SIGINT unless explicitly coded to handle them.
• App as PID 1: In containers, your application (say, a Node.js or Python app) is often PID 1, so it needs to be coded carefully or wrapped with a process manager (like tini or dumb-init).

Table: Comparison of PID 1 in Environments

Hands-On: Experimenting with PID 1 in Ubuntu Containers

Let’s see all of this in action!

Prerequisites

• Docker installed
• An Ubuntu image (or any Linux image)

Step 1: Start a Container with Default Shell

docker run -it ubuntu bash

Inside the container, run:

ps -ef

You’ll see something like:

UID   PID  PPID  C STIME TTY          TIME CMD
root    1     0  0 00:00 ?        00:00:00 bash
root   21     1  0 00:01 ?        00:00:00 ps -ef
Code language: CSS (css)

Notice: bash is running as PID 1!

Step 2: Start a Container Running Another App as PID 1

Let’s run sleep as the only process:

docker run -it ubuntu sleep 300

In another terminal, find the running container ID and exec into it:

docker exec -it <container_id> ps -ef
Code language: HTML, XML (xml)

Output:

UID   PID  PPID  C STIME TTY          TIME CMD
root    1     0  0 00:02 ?        00:00:00 sleep 300
root    7     1  0 00:03 ?        00:00:00 ps -ef
Code language: CSS (css)

Now, sleep is PID 1!

Step 3: Start a Container with systemd/init as PID 1 (Advanced)

This is not typical in containers, but possible:

docker run --privileged -d --name myinit ubuntu /sbin/init
docker exec -it myinit ps -ef

Now, /sbin/init (or /lib/systemd/systemd in some images) is PID 1.

Understanding Zombie Reaping

• In servers/VMs, init handles zombie reaping automatically.
• In containers, if your app (PID 1) doesn’t reap children, zombies accumulate.
• Best practice: Use a process manager (e.g., tini, dumb-init) as PID 1 or code your app to reap.

Example Dockerfile:

FROM ubuntu
RUN apt-get update && apt-get install -y tini
ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["your-app"]
Code language: CSS (css)

Best Practices for PID 1 in Containers

• Use a minimal init system (like tini) to handle signals and zombies.
• If your app is PID 1, ensure it handles SIGTERM, SIGINT, and reaps zombies.
• Remember: When PID 1 exits, the container stops!

Summary

• PID 1 is the “init” process in every Linux environment.
• In servers/VMs, it’s always the system init (systemd, etc.).
• In containers, your app becomes PID 1—with all its responsibilities!
• Failing to manage PID 1 properly in containers can lead to unclean shutdowns and resource leaks.
• Always test and experiment: Try running different apps as PID 1 in a container, and use process managers for production workloads.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.