How to Use the lsns Command in Linux to Inspect and Audit Active Namespaces

Modern Linux containerisation—popularised by Docker, Podman, LXC, and Kubernetes—is fundamentally built upon two core Linux kernel primitives: Control Groups (cgroups) for resource constraint and Namespaces for process isolation. Namespaces partition global system resources such that processes within an isolated namespace perceive their own distinct process trees, network interfaces, filesystem mount points, and user IDs. Understanding how to use the lsns command in Linux allows system administrators and DevOps engineers to inspect, query, and audit active kernel namespaces directly from the terminal without relying on high-level container runtimes.

Included as part of the core util-linux package, lsns (list namespaces) reads the pseudo-filesystem under /proc to discover every active namespace instance across the system. It reports unique namespace inode numbers, namespace types, process owners, and the parent process that instantiated the boundary. This comprehensive tutorial details Linux namespace types, provides practical filtering commands using lsns, demonstrates how to inspect container boundaries, and covers essential diagnostic techniques.

The 8 Linux Kernel Namespace Subsystems Audited by lsns

The Linux kernel supports eight distinct namespace types, each isolating a specific subsystem of the operating environment:

Namespace Type	Kernel Flag	Isolated Operating System Resources
mnt (Mount)	CLONE_NEWNS	Filesystem mount points and file tree root directories.
net (Network)	CLONE_NEWNET	Virtual network interfaces, IP routing tables, iptables/nftables firewall rules, and listening socket ports.
pid (Process ID)	CLONE_NEWPID	Process identification numbers. The first process inside acts as PID 1 (init/systemd replacement).
ipc (Inter-Process)	CLONE_NEWIPC	System V IPC objects, shared memory segments, message queues, and POSIX message queues.
uts (UNIX Timesharing)	CLONE_NEWUTS	System hostname and NIS domain names.
user (User IDs)	CLONE_NEWUSER	User and Group ID mappings. Allows non-root users outside to behave as root (UID 0) inside.
cgroup (Control Group)	CLONE_NEWCGROUP	Virtualised view of the cgroup hierarchy and limits under /sys/fs/cgroup.
time (Time Offsets)	CLONE_NEWTIME	Monotonic and boot time clocks without altering the hardware host clock.

Running Global Namespace Audits with lsns

To view every active namespace currently recognised by the Linux kernel, execute lsns with elevated root privileges. Running without sudo limits output to namespaces owned by your current user process:

sudo lsns

The terminal outputs a clean tabular summary:

        NS TYPE   NPROCS   PID USER  COMMAND
4026531834 time       95     1 root  /sbin/init
4026531835 cgroup     95     1 root  /sbin/init
4026531836 pid        95     1 root  /sbin/init
4026531837 user       95     1 root  /sbin/init
4026531838 uts        94     1 root  /sbin/init
4026531839 ipc        94     1 root  /sbin/init
4026531840 mnt        93     1 root  /sbin/init
4026531841 net        94     1 root  /sbin/init
4026532450 net         1  3420 root  /usr/bin/containerd-shim-runc-v2
4026532451 mnt         1  3452 1000  nginx: master process

Here, the NS column represents the unique internal inode number assigned by the kernel, NPROCS denotes the number of running processes attached to that specific namespace, and PID identifies the primary leader process.

Filtering lsns Output by Specific Namespace Type

When troubleshooting container networking or identifying unmapped mount points, displaying all eight subsystems can produce excessive output. Pass the -t (type) parameter to restrict results to a specific subsystem.

Auditing Isolated Network Namespaces

To display only container and VPN network namespaces:

sudo lsns -t net

This reveals which containers or service daemons maintain independent network stacks, routing tables, and virtual ethernet (veth) pairs.

Auditing Isolated Process (PID) Namespaces

To inspect active container process boundaries:

sudo lsns -t pid

This allows you to quickly locate container entry-point processes that serve as PID 1 within their respective sandboxes.

Inspecting Namespaces Associated with a Known PID

If you observe a suspicious or resource-intensive process in top or ps and wish to determine which namespace boundaries encapsulate it, use the -p flag followed by the target process ID:

sudo lsns -p 3452

The output lists the specific mount, network, user, and PID namespaces that govern the execution environment of PID 3452.

Customising Output Columns and JSON Formatting for Automation

For shell automation scripts and observability monitoring pipelines, lsns supports custom column projection using the -o parameter and machine-readable output formats:

Specifying Custom Output Fields

To display only the namespace ID, namespace type, process count, and parent process ID:

sudo lsns -o NS,TYPE,NPROCS,PID,PPID,COMMAND

Exporting to Machine-Readable JSON

To integrate namespace health metrics into Python monitoring scripts, Prometheus exporters, or jq parsing pipelines, pass the -J (JSON) parameter:

sudo lsns -t net -J

This produces structured JSON arrays:

{
   "namespaces": [
      {
         "ns": 4026531841,
         "type": "net",
         "nprocs": 94,
         "pid": 1,
         "user": "root",
         "command": "/sbin/init"
      },
      {
         "ns": 4026532450,
         "type": "net",
         "nprocs": 1,
         "pid": 3420,
         "user": "root",
         "command": "/usr/bin/containerd-shim-runc-v2"
      }
   ]
}

Troubleshooting Common Namespace Inspection Issues

When auditing production hosts with lsns, keep the following architectural factors in mind:

• Dangling Namespaces Without Processes: Namespaces can remain alive in the kernel even if all attached processes terminate (NPROCS = 0). This occurs when a namespace file descriptor is held open by a bind mount in /var/run/netns/ (common with iproute2: ip netns add). To remove a persistent network namespace, use ip netns delete <name>.
• Permission Denied on Container PIDs: Running lsns as a regular user will hide namespaces associated with systemd services or Docker containers running as root. Always run with sudo when performing security audits.
• Entering a Namespace Discovered by lsns: Once you locate a target namespace inode or PID using lsns, you can enter its isolated shell using the companion nsenter utility: sudo nsenter -t 3452 -n -m /bin/bash.

By incorporating lsns into your Linux administration and container debugging workflows, you gain direct visibility into low-level kernel isolation boundaries, simplifying container troubleshooting and forensic security audits.