Namespaces

A namespace wraps a global system resource so that the processes inside it see their own copy of it. That is the entire idea. The kernel has one process table, but a process in a PID namespace sees only the entries belonging to that namespace — and numbered from 1.

Namespaces are what makes a container's view of the machine false. Everything else in this course is either a resource limit or a filesystem trick.

The seven kinds

They are independent. A process can be in a new PID namespace while sharing the host's network — which is exactly what docker run --network host does, and what every pod in Kubernetes does with the containers that share it.

Seeing them

Every process exposes its namespaces as symlinks in /proc:

Those numbers are inode numbers, and they are how you answer "are these two processes in the same namespace?" — compare the inodes. Two processes with the same net:[...] number share a network stack; two with different pid:[...] numbers cannot see each other's processes.

This is also the diagnostic that settles arguments. Comparing /proc/PID/ns/net between a container process and the host tells you definitively whether --network host is in effect, regardless of what the deployment manifest claims.

unshare creates them

unshare runs a program with new namespaces of the kinds you name. The whole mechanism, in one command:

sudo unshare --fork --pid --mount-proc /bin/sh

Inside that shell:

# ps -e
  PID TTY          TIME CMD
    1 pts/0    00:00:00 sh
    5 pts/0    00:00:00 ps

Two processes on a machine running hundreds. The shell is PID 1.

Three parts of that command are load-bearing:

• --pid asks for a new PID namespace.
• --fork is required with it. The process that calls unshare does not move into the new PID namespace — only its children do, because a process's PID cannot change while it is running. --fork makes unshare fork, and the child becomes PID 1.
• --mount-proc remounts /proc inside a new mount namespace. Without it, ps reads the host's /proc and lists every process on the machine, even though the isolation is genuinely in place. The isolation is real; the view comes from /proc, which is a filesystem, which is why a PID namespace is nearly useless without a mount namespace to go with it.

PID 1 is a real job

Being PID 1 is not just a small number. The kernel gives it two special duties, and containers inherit both problems.

It reaps orphans. When a process's parent dies, the orphan is re-parented to PID 1, which is expected to wait() on it. A PID 1 that doesn't becomes a zombie factory — which is why long-running containers whose entrypoint is a plain application sometimes accumulate defunct processes.

It ignores signals it has no handler for. The default action for SIGTERM is "terminate", but the kernel suppresses that for PID 1. A shell script as PID 1 that installs no trap will not die on docker stop — it waits out the grace period and gets SIGKILLed instead. That is the usual explanation for a container that always takes ten seconds to stop.

nsenter joins an existing one

The counterpart to unshare: enter namespaces that already exist, given a PID that is in them.

sudo nsenter -t 30412 -p -m -u -n /bin/sh

That is essentially what docker exec is. It finds the container's PID 1 on the host, joins the same namespaces, and runs your command there. It is also the tool that gets you into a container whose image has no shell — nsenter runs a binary from the host's filesystem inside the container's other namespaces, so a distroless container with a broken network is still debuggable.

Next up: the root filesystem — chroot, a real Alpine userland, and what "its own /" actually means.