1pid_namespaces(7) Miscellaneous Information Manual pid_namespaces(7)
2
3
4
6 pid_namespaces - overview of Linux PID namespaces
7
9 For an overview of namespaces, see namespaces(7).
10
11 PID namespaces isolate the process ID number space, meaning that pro‐
12 cesses in different PID namespaces can have the same PID. PID name‐
13 spaces allow containers to provide functionality such as suspending/re‐
14 suming the set of processes in the container and migrating the con‐
15 tainer to a new host while the processes inside the container maintain
16 the same PIDs.
17
18 PIDs in a new PID namespace start at 1, somewhat like a standalone sys‐
19 tem, and calls to fork(2), vfork(2), or clone(2) will produce processes
20 with PIDs that are unique within the namespace.
21
22 Use of PID namespaces requires a kernel that is configured with the
23 CONFIG_PID_NS option.
24
25 The namespace init process
26 The first process created in a new namespace (i.e., the process created
27 using clone(2) with the CLONE_NEWPID flag, or the first child created
28 by a process after a call to unshare(2) using the CLONE_NEWPID flag)
29 has the PID 1, and is the "init" process for the namespace (see
30 init(1)). This process becomes the parent of any child processes that
31 are orphaned because a process that resides in this PID namespace ter‐
32 minated (see below for further details).
33
34 If the "init" process of a PID namespace terminates, the kernel termi‐
35 nates all of the processes in the namespace via a SIGKILL signal. This
36 behavior reflects the fact that the "init" process is essential for the
37 correct operation of a PID namespace. In this case, a subsequent
38 fork(2) into this PID namespace fail with the error ENOMEM; it is not
39 possible to create a new process in a PID namespace whose "init"
40 process has terminated. Such scenarios can occur when, for example, a
41 process uses an open file descriptor for a /proc/pid/ns/pid file corre‐
42 sponding to a process that was in a namespace to setns(2) into that
43 namespace after the "init" process has terminated. Another possible
44 scenario can occur after a call to unshare(2): if the first child sub‐
45 sequently created by a fork(2) terminates, then subsequent calls to
46 fork(2) fail with ENOMEM.
47
48 Only signals for which the "init" process has established a signal han‐
49 dler can be sent to the "init" process by other members of the PID
50 namespace. This restriction applies even to privileged processes, and
51 prevents other members of the PID namespace from accidentally killing
52 the "init" process.
53
54 Likewise, a process in an ancestor namespace can—subject to the usual
55 permission checks described in kill(2)—send signals to the "init"
56 process of a child PID namespace only if the "init" process has estab‐
57 lished a handler for that signal. (Within the handler, the siginfo_t
58 si_pid field described in sigaction(2) will be zero.) SIGKILL or
59 SIGSTOP are treated exceptionally: these signals are forcibly de