diff options
Diffstat (limited to 'man7/pid_namespaces.7')
| -rw-r--r-- | man7/pid_namespaces.7 | 108 |
1 files changed, 54 insertions, 54 deletions
diff --git a/man7/pid_namespaces.7 b/man7/pid_namespaces.7 index c886a034d..e299db884 100644 --- a/man7/pid_namespaces.7 +++ b/man7/pid_namespaces.7 @@ -9,7 +9,7 @@ pid_namespaces \- overview of Linux PID namespaces .SH DESCRIPTION For an overview of namespaces, see -.BR namespaces (7). +.MR namespaces 7 . .P PID namespaces isolate the process ID number space, meaning that processes in different PID namespaces can have the same PID. @@ -20,10 +20,10 @@ while the processes inside the container maintain the same PIDs. .P PIDs in a new PID namespace start at 1, somewhat like a standalone system, and calls to -.BR fork (2), -.BR vfork (2), +.MR fork 2 , +.MR vfork 2 , or -.BR clone (2) +.MR clone 2 will produce processes with PIDs that are unique within the namespace. .P Use of PID namespaces requires a kernel that is configured with the @@ -35,15 +35,15 @@ option. .SS The namespace "init" process The first process created in a new namespace (i.e., the process created using -.BR clone (2) +.MR clone 2 with the .B CLONE_NEWPID flag, or the first child created by a process after a call to -.BR unshare (2) +.MR unshare 2 using the .B CLONE_NEWPID flag) has the PID 1, and is the "init" process for the namespace (see -.BR init (1)). +.MR init 1 ). This process becomes the parent of any child processes that are orphaned because a process that resides in this PID namespace terminated (see below for further details). @@ -55,7 +55,7 @@ signal. This behavior reflects the fact that the "init" process is essential for the correct operation of a PID namespace. In this case, a subsequent -.BR fork (2) +.MR fork 2 into this PID namespace fail with the error .BR ENOMEM ; it is not possible to create a new process in a PID namespace whose "init" @@ -64,14 +64,14 @@ Such scenarios can occur when, for example, a process uses an open file descriptor for a .IR /proc/ pid /ns/pid file corresponding to a process that was in a namespace to -.BR setns (2) +.MR setns 2 into that namespace after the "init" process has terminated. Another possible scenario can occur after a call to -.BR unshare (2): +.MR unshare 2 : if the first child subsequently created by a -.BR fork (2) +.MR fork 2 terminates, then subsequent calls to -.BR fork (2) +.MR fork 2 fail with .BR ENOMEM . .P @@ -83,14 +83,14 @@ accidentally killing the "init" process. .P Likewise, a process in an ancestor namespace can\[em]subject to the usual permission checks described in -.BR kill (2)\[em]send +.MR kill 2 \[em]send signals to the "init" process of a child PID namespace only if the "init" process has established a handler for that signal. (Within the handler, the .I siginfo_t .I si_pid field described in -.BR sigaction (2) +.MR sigaction 2 will be zero.) .B SIGKILL or @@ -102,10 +102,10 @@ and so will result in the usual actions associated with those signals (respectively, terminating and stopping the process). .P Starting with Linux 3.4, the -.BR reboot (2) +.MR reboot 2 system call causes a signal to be sent to the namespace "init" process. See -.BR reboot (2) +.MR reboot 2 for more details. .\" .\" ============================================================ @@ -116,9 +116,9 @@ each PID namespace has a parent, except for the initial ("root") PID namespace. The parent of a PID namespace is the PID namespace of the process that created the namespace using -.BR clone (2) +.MR clone 2 or -.BR unshare (2). +.MR unshare 2 . PID namespaces thus form a tree, with all namespaces ultimately tracing their ancestry to the root namespace. Since Linux 3.7, @@ -135,9 +135,9 @@ system calls that specify a process ID. Conversely, the processes in a child PID namespace can't see processes in the parent and further removed ancestor namespaces. More succinctly: a process can see (e.g., send signals with -.BR kill (2), +.MR kill 2 , set nice values with -.BR setpriority (2), +.MR setpriority 2 , etc.) only processes contained in its own PID namespace and in descendants of that namespace. .P @@ -149,7 +149,7 @@ System calls that operate on process IDs always operate using the process ID that is visible in the PID namespace of the caller. A call to -.BR getpid (2) +.MR getpid 2 always returns the PID associated with the namespace in which the process was created. .P @@ -157,20 +157,20 @@ Some processes in a PID namespace may have parents that are outside of the namespace. For example, the parent of the initial process in the namespace (i.e., the -.BR init (1) +.MR init 1 process with PID 1) is necessarily in another namespace. Likewise, the direct children of a process that uses -.BR setns (2) +.MR setns 2 to cause its children to join a PID namespace are in a different PID namespace from the caller of -.BR setns (2). +.MR setns 2 . Calls to -.BR getppid (2) +.MR getppid 2 for such processes return 0. .P While processes may freely descend into child PID namespaces (e.g., using -.BR setns (2) +.MR setns 2 with a PID namespace file descriptor), they may not move in the other direction. That is to say, processes may not enter any ancestor namespaces @@ -179,19 +179,19 @@ Changing PID namespaces is a one-way operation. .P The .B NS_GET_PARENT -.BR ioctl (2) +.MR ioctl 2 operation can be used to discover the parental relationship between PID namespaces; see -.BR ioctl_ns (2). +.MR ioctl_ns 2 . .\" .\" ============================================================ .\" .SS setns(2) and unshare(2) semantics Calls to -.BR setns (2) +.MR setns 2 that specify a PID namespace file descriptor and calls to -.BR unshare (2) +.MR unshare 2 with the .B CLONE_NEWPID flag cause children subsequently created @@ -199,7 +199,7 @@ by the caller to be placed in a different PID namespace from the caller. (Since Linux 4.12, that PID namespace is shown via the .IR /proc/ pid /ns/pid_for_children file, as described in -.BR namespaces (7).) +.MR namespaces 7 .) These calls do not, however, change the PID namespace of the calling process, because doing so would change the caller's idea of its own PID @@ -216,7 +216,7 @@ the parent of a process is either in the same namespace or resides in the immediate parent PID namespace. .P A process may call -.BR unshare (2) +.MR unshare 2 with the .B CLONE_NEWPID flag only once. @@ -230,13 +230,13 @@ symbolic link will be empty until the first child is created in the namespace. When a child process becomes orphaned, it is reparented to the "init" process in the PID namespace of its parent (unless one of the nearer ancestors of the parent employed the -.BR prctl (2) +.MR prctl 2 .B PR_SET_CHILD_SUBREAPER command to mark itself as the reaper of orphaned descendant processes). Note that because of the -.BR setns (2) +.MR setns 2 and -.BR unshare (2) +.MR unshare 2 semantics described above, this may be the "init" process in the PID namespace that is the .I parent @@ -256,7 +256,7 @@ Threads are required to be in the same PID namespace such that the threads in a process can send signals to each other. Similarly, it must be possible to see all of the threads of a process in the -.BR proc (5) +.MR proc 5 filesystem. Additionally, if two threads were in different PID namespaces, the process ID of the process sending a signal @@ -264,7 +264,7 @@ could not be meaningfully encoded when a signal is sent (see the description of the .I siginfo_t type in -.BR sigaction (2)). +.MR sigaction 2 ). Since this is computed when a signal is enqueued, a signal queue shared by processes in multiple PID namespaces would defeat that. @@ -303,16 +303,16 @@ it is useful for the child to change its root directory and mount a new procfs instance at .I /proc so that tools such as -.BR ps (1) +.MR ps 1 work correctly. If a new mount namespace is simultaneously created by including .B CLONE_NEWNS in the .I flags argument of -.BR clone (2) +.MR clone 2 or -.BR unshare (2), +.MR unshare 2 , then it isn't necessary to change the root directory: a new procfs instance can be mounted directly over .IR /proc . @@ -328,7 +328,7 @@ $ mount \-t proc proc /proc .in .P Calling -.BR readlink (2) +.MR readlink 2 on the path .I /proc/self yields the process ID of the caller in the PID namespace of the procfs mount @@ -366,23 +366,23 @@ When a process ID is passed over a UNIX domain socket to a process in a different PID namespace (see the description of .B SCM_CREDENTIALS in -.BR unix (7)), +.MR unix 7 ), it is translated into the corresponding PID value in the receiving process's PID namespace. .SH STANDARDS Linux. .SH EXAMPLES See -.BR user_namespaces (7). +.MR user_namespaces 7 . .SH SEE ALSO -.BR clone (2), -.BR reboot (2), -.BR setns (2), -.BR unshare (2), -.BR proc (5), -.BR capabilities (7), -.BR credentials (7), -.BR mount_namespaces (7), -.BR namespaces (7), -.BR user_namespaces (7), -.BR switch_root (8) +.MR clone 2 , +.MR reboot 2 , +.MR setns 2 , +.MR unshare 2 , +.MR proc 5 , +.MR capabilities 7 , +.MR credentials 7 , +.MR mount_namespaces 7 , +.MR namespaces 7 , +.MR user_namespaces 7 , +.MR switch_root 8 |