Analyzing Namespace Reference Counts

In this lesson, you will learn how to identify "zombie" namespaces by inspecting the kernel’s internal reference counting mechanism to determine why they refuse to be garbage collected.

The Problem of Persistent Namespaces

When you delete a network namespace (e.g., ip netns del myns), the kernel is supposed to trigger its garbage collection process. However, if the namespace lingers in your ip netns list, it is almost always because the kernel’s internal reference count has not reached zero. Every object pointing to the namespace—such as a process, a socket, or an open file descriptor—holds an active reference. If just one process or kernel module forgets to release that reference, the namespace is effectively leaked.

Inspecting the Reference Count

To diagnose why a namespace is stuck, we look at the ns_common structure within the kernel. While kernel developers use struct ns_common directly, you can observe the effect of these references from user space by examining the /proc/[pid]/ns/ entries and the kernel's slab allocator.

A common culprit is an abandoned process or an active socket holding a reference. You can use the lsns tool to identify active namespaces, but for deep debugging, we look for leaked references by checking the task list. If a namespace is pinned, you can often find the offending process by iterating through the task list:

# Look for processes pinned to the namespace via /proc
for pid in $(ls /proc | grep -E '^[0-9]+$'); do
    readlink /proc/$pid/ns/net | grep -q "net:\[[YOUR_NS_INODE]\]" && echo "Process $pid is holding this NS"
done

Why Garbage Collection Fails

When the reference count is greater than one, the net_ns structure cannot be freed. This happens frequently with:

1. Dangling Sockets: A socket created inside the namespace that wasn't closed before the namespace was unmounted.
2. Mount Points: If a file inside the namespace (like /proc/net/dev) is still mounted in the host, it acts as a persistent reference.
3. BPF Filters: An eBPF program attached to a namespace interface (via tc or XDP) might hold a reference to the net struct to ensure it doesn't vanish while traffic is flowing.

Key Takeaway: A namespace remains resident in kernel memory as long as its reference count is above zero; identifying leaked references requires tracking down every process or socket that holds a lingering file descriptor or pointer to that specific net_ns object.