1pid_namespaces(7)      Miscellaneous Information Manual      pid_namespaces(7)
2
3
4

NAME

6       pid_namespaces - overview of Linux PID namespaces
7

DESCRIPTION

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