On a Linux host, `ip netns list` shows a network namespace with no processes running in it at all. What keeps a namespace object alive when nothing is running inside it?
answer
- a counted object, not process state
- processes are only one holder
- a mount is a reference too
- that is what /run/netns is for
- physical devices go home on teardown
basics
~20 sA namespace lives as long as something references it: a member process, an open file descriptor on /proc/PID/ns/*, a bind mount of that file, or a child namespace. ip netns add deliberately bind-mounts the namespace under /run/netns so it outlives the process that created it.
solid answer
~50 sNamespaces are reference-counted kernel objects, not process attributes that vanish with the last task. The references that keep one alive are: a process that is a member; an open file descriptor on the corresponding `/proc/<pid>/ns/<type>` magic symlink; a bind mount of that file somewhere in the filesystem; and, for nesting types, a child namespace held beneath it. `ip netns add blue` uses the third mechanism — it creates an empty file at `/run/netns/blue` and bind-mounts the new network namespace onto it, so the namespace survives even though the process that created it has exited. That is what lets you later run `nsenter --net=/run/netns/blue …` or `ip netns exec blue …` and find the interfaces and routes exactly as you left them. `ip netns delete blue` unmounts and removes that file; when the last reference goes, the kernel tears the namespace down, destroying its virtual interfaces and moving any physical device back to the initial network namespace.
code
bash · 6 linesip netns add blue
mountpoint /run/netns/blue # the pin that outlives the creating process
readlink /proc/self/ns/net # net:[<inode>] identifies a namespace
nsenter --net=/run/netns/blue ip link show
ip netns delete blue # unmount the pin; last reference gonego deeper
Know that a namespace can exist without any process in it, and that /proc/PID/ns holds an entry per namespace type identifying which one the process belongs to.
Explain reference counting: a member process, an open descriptor, a bind mount, or a child namespace each keeps it alive, and ip netns pins one under /run/netns on purpose.
Reason about leaks and cleanup — a crashed tool leaving pinned namespaces, a delete that removed only the name — and know what teardown destroys versus what it returns to the initial namespace.
Own lifecycle policy for whatever creates namespaces on your hosts: who pins them, who is responsible for unpinning, and how leaked kernel objects are detected before they accumulate.
## Namespaces are objects, not process state It is tempting to think of a namespace as something a process *has*, which would mean it disappears when the last member exits. The kernel models it the other way round: a namespace is an object with a reference count, and being a member is just one kind of reference. The object is exposed through `/proc/<pid>/ns/`, whose entries are *magic symlinks*. Reading one gives a string like `net:[4026532280]` — the type plus the namespace's inode number. That inode number is the identity: two processes are in the same namespace exactly when their symlinks report the same inode. ```bash readlink /proc/self/ns/net # net:[4026531840] ``` ## What counts as a reference Four things hold a namespace alive: 1. **A member process.** The obvious one. While any task is in the namespace, it stays. 2. **An open file descriptor** on the `/proc/<pid>/ns/<type>` file. Opening it takes a reference; this is the handle `setns(2)` consumes when a process joins an existing namespace. 3. **A bind mount** of that file elsewhere in the filesystem. A mount is a reference like any other, and unlike an fd it survives every process exiting. 4. **A child namespace.** Namespaces of some types nest — a user namespace is the parent of the namespaces created under it, and a PID namespace has descendants — and the descendant holds the ancestor alive. When the count reaches zero the kernel destroys the namespace and everything it exclusively owned. ## How `ip netns` uses the third mechanism The `ip netns` subcommand is a thin wrapper over exactly this idea. `ip netns add blue`: - creates a new network namespace, - touches an empty file at `/run/netns/blue`, - bind-mounts the namespace's `ns/net` file onto it. The creating process then exits, and the namespace persists because the bind mount references it. `ip netns list` is essentially a listing of `/run/netns`. You can confirm the mechanism directly: ```bash ip netns add blue mountpoint /run/netns/blue # /run/netns/blue is a mountpoint nsenter --net=/run/netns/blue ip link show ``` `ip netns exec blue …` and `nsenter --net=/run/netns/blue …` both work by opening that path and calling `setns(2)` on the resulting descriptor. This is also why namespaces created by other tooling do not show up in `ip netns list`: they are perfectly real, but nobody bind-mounted them under `/run/netns`, so the wrapper cannot see them. `lsns` enumerates namespaces from `/proc` instead and does see them. ## What teardown actually destroys When the last reference to a network namespace goes away, the kernel: - destroys the namespace's virtual network devices — veth pairs, bridges, dummy interfaces created inside it, - moves any **physical** device that was assigned to it back to the initial network namespace, rather than destroying hardware, - discards the namespace's routing tables, netfilter rule set, and socket state. `ip netns delete blue` performs the unmount and removes the file; if a process is still running in the namespace, deleting the file only removes the name — the namespace itself lives on until that process exits. ## Where this bites in practice **Leaked namespaces.** A tool that creates namespaces and pins them with bind mounts, then crashes before cleaning up, leaves objects with no processes and no owner. They consume kernel memory and their virtual interfaces stay allocated. Nothing reaps them; someone has to unmount the pin. **"I deleted it and it is still there."** The name went away, a reference did not. Some process still has the namespace open, or another bind mount of it exists somewhere. **A namespace with no processes is normal, not broken.** A network namespace holding one end of a veth pair, prepared in advance for a workload that has not started yet, is a legitimate configuration — the pinning is the point. ## The one-line answer A namespace is a reference-counted kernel object. Processes are only one way to reference it; an open descriptor, a bind mount, or a child namespace will do just as well, and `ip netns` deliberately uses the bind mount so that namespaces have names and lifetimes independent of any process.
- Why do namespaces created by other tooling not appear in `ip netns list`?Because that command lists `/run/netns`, which only contains the bind-mount pins `ip netns add` created. Namespaces made by any other means are entirely real but unnamed there. `lsns` enumerates them from `/proc` instead, and `readlink /proc/<pid>/ns/net` identifies the one a given process is in.
- What happens to a physical network interface that was moved into a network namespace when that namespace is destroyed?The kernel moves it back to the initial network namespace rather than destroying it, since it represents real hardware. Virtual devices created inside — veth ends, bridges, dummies — are destroyed outright, along with the namespace's routes, netfilter rules and socket state.
- You ran `ip netns delete blue` and a process is still running inside it. What have you actually done?Removed the name, not the namespace. Deleting unmounts and unlinks `/run/netns/blue`, dropping that one reference, but the member process holds another. The namespace keeps running unnamed until that process exits, at which point the count reaches zero and the kernel tears it down.
saying these in an interview costs you the question
- Says a namespace dies as soon as its last process exits
- Thinks /proc/PID/ns entries are ordinary symlinks to files
- Believes ip netns list shows every namespace on the host
- Assumes deleting the pin always destroys the namespace
- Says physical interfaces are destroyed with the namespace