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

Environment	PID 1 Process	Usually Runs	Can be Any Executable?	Responsibilities
Physical Server	init/systemd	Kernel booted OS	No	System/service management, reaping
Virtual Machine	init/systemd	Kernel booted OS	No	System/service management, reaping
Container	Entry CMD/ENTRYPOINT	Your app/bash	Yes	Running the app, reaping, signal mgmt

---

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.

---