In this lesson, you will learn how the Linux kernel uses the persistence of namespace inodes to maintain identity and state even after the last process inside a namespace has exited.
The Role of Persistent Inodes
Usually, a Linux namespace is destroyed the moment the last process associated with it terminates. However, there are scenarios where we need the namespace to "survive" this teardown. This is achieved through namespace metadata persistence.
The kernel tracks every namespace via a unique inode within the nsfs (Namespace Filesystem). As long as a reference to that namespace exists, the kernel keeps the namespace's internal data structures—such as its network routing tables, mount points, or process IDs—intact in memory.
Forcing Persistence via Bind Mounts
The most common way to manifest this persistence is by bind-mounting a namespace file from /proc/[pid]/ns/ to a permanent location in the filesystem.
When you run:
mount --bind /proc/1234/ns/net /var/run/netns/my_container
You create a persistent reference. Even if process 1234 dies, the kernel increments the reference count on the inode associated with that network namespace because the mount point acts as a "dangling" holder of that reference. Because the inode remains "in use," the kernel will not trigger its garbage collection routines. The namespace remains alive, allowing you to re-attach to it later or inspect its state long after the container's processes have exited.
Why This Matters for Metadata
This mechanism is critical for operational stability. By holding a namespace open, the kernel ensures that the metadata associated with that namespace (such as assigned IP addresses, interface configurations, or persistent IPC keys) is not purged. For deep troubleshooting, this means you can perform post-mortem analysis on a network stack that would have otherwise vanished into the ether. You are essentially telling the kernel, "I am still holding onto this metadata; do not reclaim the resources until I unmount the reference."
Key Takeaway: A namespace persists as long as there is an active reference count, which is maintained by the kernel through inode-based filesystem entries, even after all processes within that namespace have terminated.