Linux – What happens if the last process in a namespace exits

linuxnamespacenetwork-namespaces

I am running Linux.

I have a single process in a mount namespace.
I did in this process a mount -t tmpfs tmpfs /mountpoint.

What happens if the process exits and there are no more processes in that mount namespace?
Will the filesystem be automatically unmounted?
Will the mount namespace be destroyed?
If the namespaces and the mount are still active how do I access it?

What happens to tun/tap/macvtap interfaces if a network namespace has no more processes?

Best Answer

I was wondering the same thing, and so I ran a little test (on kernel 4.20.0, using unshare from util-linux 2.33; the manpage for unshare in that version has some notes on shared/private mounts that are worth reading, and YMMV if you are using an older version).

TL;DR: Yes, the filesystem is unmounted when the last process in the namespace exits.

In my case, the device I'm testing with is dm-6, and it is not mounted in the "outer" namespace.

Window 1:

cd /sys/fs/ext4
ls -d dm-6
# No such file or directory

Window 2:

unshare -m
mount /dev/dm-6 /mnt/tmp
# don't exit yet, keep the namespace active

Window 3: Do the same thing as window 1.

Window 1:

ls -d dm-6
# exists now

Window 2: Exit the unshare environment

Window 1: Check again, dm-6 is still there

Window 3: Exit the unshare environment

Window 1: Check again, dm-6 is gone again

Another useful demo / test: Similar idea, but instead of having 3 windows, enter and exit Window 2 twice. Check dmesg or logs, and verified that the kernel message that it mounted the filesystem appears twice in this case.

Related Solutions

Linux – Switching Network Namespace Doesn’t Change /sys/class/net

Let's look into man 5 sysfs:

/sys/class/net
    Each  of the entries in this directory is a symbolic link representing
    one of the real or virtual networking devices that are visible in 
    the network namespace of the process that is accessing the directory.

So, according to this manpage, the output of ls /sys/class/net must depend on the network namespace of the ls process. But... Actual behavior does not seem to be as described in this manpage. There is a nice kernel documentation about how it works.

Each sysfs mount has a namespace tag associated with it. This tag is set when sysfs gets mounted and depends on the network namespace of the calling process. Each sysfs entry (e.g. an entry in /sys/class/net) also may have a namespace tag associated with it.

When you iterate over the sysfs directory, the kernel obtains the namespace tag of the sysfs mount, and then it iterates over the entries, filtering out those which have different namespace tag.

So, it turns out that the results of iterating over the /sys/class/net depend on the network namespace of the process which initiated /sys mount rather than on the network namespace of the current process, thus, you must always mount /sys in the current network namespace (from any process belonging to this namespace) to see the correct results.

Linux – file that associates a thread to its network namespace

There is a file that associates a thread to its network namespace:

/proc/[PID]/task/[TID]/ns/net

where TID is the thread ID. This solved my issue.

Best Answer

Related Solutions

Linux – Switching Network Namespace Doesn’t Change /sys/class/net

Linux – file that associates a thread to its network namespace

Related Question