Container Creation

Everything in this course so far has been one mechanism at a time. docker run is all of them in order, and the order is not arbitrary — each step depends on the one before it.

The sequence

1. resolve the image: fetch the manifest, make sure every layer is local
2. mount the overlay: lowerdir = the image layers, upperdir = a fresh directory
3. unshare the namespaces
     CLONE_NEWPID    own process numbering
     CLONE_NEWNS     own mount table
     CLONE_NEWNET    own interfaces, routes, ports
     CLONE_NEWUTS    own hostname
     CLONE_NEWIPC    own SysV/mqueue tables
     CLONE_NEWUSER   own uid map          (optional; the default in rootless)
4. create the cgroups and write the limits: memory, cpu, pids, io, devices
5. wire the network: veth pair, one end into the netns, address, NAT rule
6. pivot_root into the merged overlay, then unmount the old root
7. exec the entrypoint — it becomes PID 1 of the new PID namespace

Step 3 must precede step 6, because pivot_root has to happen in a mount namespace of your own or you would move the host's root. Step 4 must precede step 7, or the process runs unlimited for the moment before its limits exist — a real race, and the reason the runtime configures the cgroup and then hands control to the child rather than the other way round.

The kernel provides every one of these pieces. runc — the OCI runtime Docker actually shells out to — is a few thousand lines of Go that calls them in this order and gets the error handling right. There is no container object anywhere in the kernel.

Life states

docker run is not a primitive: it is create then start, and the split is visible in the lifecycle.

• created — bundle and namespaces are ready, the entrypoint has not been executed.
• running — the entrypoint is alive as PID 1.
• paused — every task frozen by the cgroup freezer; the processes still exist and hold their memory.
• stopped — the entrypoint exited. The upper layer and the metadata are still on disk, which is why you can start it again and why docker ps -a still lists it.
• removed — rootfs and metadata gone. This is the only transition that destroys data.

The transitions people get wrong are the ones the exercise tests. A stopped container can start again — it is not a corpse, it is a container with no running process. A running container cannot be removed; docker rm on it fails and tells you to stop it first (docker rm -f is a stop followed by a remove, not an exception to the rule). And paused is not stopped: resume goes back to running, and the frozen processes never knew.

Why the exercise is a simulator

Executing step 3 needs CAP_SYS_ADMIN and steps 4 and 5 need root on the host — none of which a grader sandbox has. What is left is the part every runtime has to get right anyway and frequently does not: the state machine, in which the answer to most commands is that they are not legal from here.

Your exercise: Container State Machine

Model the five states and the eight legal transitions. Anything not in that set is an error naming the command and the state it was refused from — which is precisely what the Docker CLI prints back at you, and precisely the discipline that stops docker rm deleting a running database.