[Are there] other tools/commands geared to working with and debugging namespaces ?
nsenter is the most important one. There are some more, but not very many. I think I can usefully attempt to list them all.
/proc/[pid]/ns/* - You already know about this, because you looked at
nsenter. There are a couple more specifics in namespaces(7) :
- The above files appear as symbolic links. Running
ls -l will show the namespace type, and a unique identifier.
- You can keep a permanent reference to a namespace by bind-mounting the above files. If you think this sounds a bit weird, I agree with you, but it can be useful in some cases :-).
- lsns - It crawls
/proc for you, and lists all the different namespaces that are being used.
/proc/[pid]/mountinfo describes the mount namespace. It is documented in proc(5).
Take care the first time you look at it, because there are many columns. For example, there are two different "options" columns with potentially differing values for
ro. The difference is that the column for "mount options" can vary between bind-mounts of the same filesystem.
findmnt is the standard command to list mounted filesystems. It has an option
--task TID - so you can use it to parse the
mountinfo file of any process. (A PID value is also a valid TID).
/proc/[pid]/gid_map, for user_namespaces.
ip command used to control network interfaces:
- ip netns provides some commands for network namespaces specifically. I.e. it just uses the
net file in
/proc/[pid]/ns/ as described above.
ip link can show information about
veth peers, including a local identifier for the netns the peer is in.
ip netns list-id or
lsns -t net will list network namespaces including this local identifier. I'm not exactly sure how you work with these local identifiers, it seems a bit obscure. But I think this QA mentions everything you can do with them: How to find the network namespace of a veth peer ifindex?
ip also lets you move an interface from one netns to another. Although that's not so much about debugging.
"I’m looking at you, single binary
Adapted from How-to Debug a Running Docker Container from a Separate Container :
There is a problem with using
nsenter. If you enter the mount namespace of a container, you can only run commands that were included in the container. But the point of Docker containers is that they only need to include the application itself!
The trick is that you can access the files inside the container, using
/proc/[pid]/root/. (Documented in
This is very convenient if you have entered the PID namespace of a container, because you can use
/proc/1/root/. At that point, you don't have to search for the right PID :-).
Having entered the PID namespace, it could also be quite convenient if you know the process you want to attach a debugger to will be PID 1 (or perhaps PID 2) inside the container :-). Alternatively, if your application/container is multi-process, you can use your favourite
ps command to look at the different processes.