0

From https://man7.org/linux/man-pages/man1/n.1.html :

By default, a new namespace remains in existence only as long as it has at least one member process. A namespace can be made persistent— that is, pinned into existence even when it has no member processes— by bind mounting the corresponding /proc/PID/ns/ns-type file.

Which PID is being used in the file path of the bind mount source? Isn't the whole point of a bind mount point when creating namespaces that the namespace doesn't rely on the existence of a PID?

If I create a network namespace with clone() using the CLONE_NEWNET flag and then create a bind mount using the PID of new process that was created, and then I kill the new process, I would think that the /proc/PID/ns/net file disappears, but then the /var/run/netns/<netns name> would also get deleted and the network namespace wouldn't persist.

1
  • No, /proc/PID/ns/net does not disappear when PID (and all the processes which share the same namespace) terminates, if it's bind-mounted elsewhere. Have you considered doing some simple testing?
    – user313992
    Oct 23, 2021 at 16:54

1 Answer 1

0

Userland software, running in processes, can't create namespace outside of any process.

Hence, you use the PID of the namespace-creating process (or one of its children).

If I create a network namespace with clone() using the CLONE_NEWNET flag and then create a bind mount using the PID of new process that was created, and then I kill the new process, I would think that the /proc/PID/ns/net file disappears,

Let's take "file" with big quotation marks here. The virtual filesystem entry disappears, but ...

but then the /var/run/netns/ would also get deleted

"delete" is something you do to actual files, and it's not applicable here. The PID would disappear, but things that you could access as some virtual file system entry under a path that contain that PID would become inaccessible that way. But:

but then the /var/run/netns/ would also get deleted and the network namespace wouldn't persist.

is wrong, because the bind mount would add a kernel-internal reference to the namespace, so that it's not becoming unused, and thus, will persist.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .