{
    "mode": "man",
    "parameter": "PID_NAMESPACES",
    "section": "7",
    "url": "https://www.chedong.com/phpMan.php/man/PID_NAMESPACES/7/json",
    "generated": "2026-10-04T01:14:04Z",
    "sections": {
        "NAME": {
            "content": "pidnamespaces - overview of Linux PID namespaces\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "For an overview of namespaces, see namespaces(7).\n\nPID  namespaces  isolate the process ID number space, meaning that processes in different PID\nnamespaces can have the same PID.  PID namespaces allow containers to  provide  functionality\nsuch as suspending/resuming the set of processes in the container and migrating the container\nto a new host while the processes inside the container maintain the same PIDs.\n\nPIDs  in  a  new  PID  namespace  start at 1, somewhat like a standalone system, and calls to\nfork(2), vfork(2), or clone(2) will produce processes with PIDs that are  unique  within  the\nnamespace.\n\nUse of PID namespaces requires a kernel that is configured with the CONFIGPIDNS option.\n",
            "subsections": [
                {
                    "name": "The namespace init process",
                    "content": "The  first  process created in a new namespace (i.e., the process created using clone(2) with\nthe CLONENEWPID flag, or the first child created by a process after a call to unshare(2) us‐\ning the CLONENEWPID flag) has the PID 1, and is the \"init\" process for  the  namespace  (see\ninit(1)).  This process becomes the parent of any child processes that are orphaned because a\nprocess that resides in this PID namespace terminated (see below for further details).\n\nIf  the  \"init\"  process  of  a  PID  namespace  terminates, the kernel terminates all of the\nprocesses in the namespace via a SIGKILL signal.  This behavior reflects the  fact  that  the\n\"init\"  process  is  essential for the correct operation of a PID namespace.  In this case, a\nsubsequent fork(2) into this PID namespace fail with the error ENOMEM; it is not possible  to\ncreate  a new process in a PID namespace whose \"init\" process has terminated.  Such scenarios\ncan occur when, for example, a process uses an open file descriptor  for  a  /proc/pid/ns/pid\nfile corresponding to a process that was in a namespace to setns(2) into that namespace after\nthe  \"init\"  process has terminated.  Another possible scenario can occur after a call to un‐\nshare(2): if the first child subsequently created by a fork(2)  terminates,  then  subsequent\ncalls to fork(2) fail with ENOMEM.\n\nOnly signals for which the \"init\" process has established a signal handler can be sent to the\n\"init\" process by other members of the PID namespace.  This restriction applies even to priv‐\nileged  processes,  and prevents other members of the PID namespace from accidentally killing\nthe \"init\" process.\n\nLikewise, a process in an ancestor namespace can—subject to the usual permission  checks  de‐\nscribed  in  kill(2)—send  signals to the \"init\" process of a child PID namespace only if the\n\"init\" process has established a handler for that signal.  (Within the handler, the siginfot\nsipid field described in sigaction(2) will be zero.)  SIGKILL or SIGSTOP are treated  excep‐\ntionally:  these  signals  are  forcibly  delivered when sent from an ancestor PID namespace.\nNeither of these signals can be caught by the \"init\" process, and so will result in the usual\nactions associated with those signals (respectively, terminating and stopping the process).\n\nStarting with Linux 3.4, the reboot(2) system call causes a signal to be sent  to  the  name‐\nspace \"init\" process.  See reboot(2) for more details.\n"
                },
                {
                    "name": "Nesting PID namespaces",
                    "content": "PID  namespaces  can  be  nested:  each  PID  namespace  has a parent, except for the initial\n(\"root\") PID namespace.  The parent of a PID namespace is the PID namespace  of  the  process\nthat  created  the  namespace using clone(2) or unshare(2).  PID namespaces thus form a tree,\nwith all namespaces ultimately tracing their ancestry to the  root  namespace.   Since  Linux\n3.7, the kernel limits the maximum nesting depth for PID namespaces to 32.\n\nA  process  is  visible to other processes in its PID namespace, and to the processes in each\ndirect ancestor PID namespace going back to the root PID namespace.  In this context,  \"visi‐\nble\"  means  that one process can be the target of operations by another process using system\ncalls that specify a process ID.  Conversely, the processes in a child  PID  namespace  can't\nsee  processes  in  the  parent  and further removed ancestor namespaces.  More succinctly: a\nprocess can see (e.g., send signals with kill(2), set nice values with setpriority(2),  etc.)\nonly processes contained in its own PID namespace and in descendants of that namespace.\n\nA process has one process ID in each of the layers of the PID namespace hierarchy in which is\nvisible, and walking back though each direct ancestor namespace through to the root PID name‐\nspace.   System calls that operate on process IDs always operate using the process ID that is\nvisible in the PID namespace of the caller.  A call to getpid(2) always returns the PID asso‐\nciated with the namespace in which the process was created.\n\nSome processes in a PID namespace may have parents that are outside of  the  namespace.   For\nexample,  the  parent of the initial process in the namespace (i.e., the init(1) process with\nPID 1) is necessarily in another namespace.  Likewise, the direct children of a process  that\nuses  setns(2) to cause its children to join a PID namespace are in a different PID namespace\nfrom the caller of setns(2).  Calls to getppid(2) for such processes return 0.\n\nWhile processes may freely descend into child PID namespaces (e.g., using setns(2) with a PID\nnamespace file descriptor), they may not move in  the  other  direction.   That  is  to  say,\nprocesses  may  not  enter any ancestor namespaces (parent, grandparent, etc.).  Changing PID\nnamespaces is a one-way operation.\n\nThe NSGETPARENT ioctl(2) operation can be used to discover the  parental  relationship  be‐\ntween PID namespaces; see ioctlns(2).\n"
                },
                {
                    "name": "setns(2) and unshare(2) semantics",
                    "content": "Calls  to  setns(2) that specify a PID namespace file descriptor and calls to unshare(2) with\nthe CLONENEWPID flag cause children subsequently created by the caller to  be  placed  in  a\ndifferent  PID namespace from the caller.  (Since Linux 4.12, that PID namespace is shown via\nthe /proc/pid/ns/pidforchildren file, as described in namespaces(7).)  These calls do  not,\nhowever,  change  the PID namespace of the calling process, because doing so would change the\ncaller's idea of its own PID (as reported by getpid()), which would break  many  applications\nand libraries.\n\nTo  put  things  another  way:  a  process's  PID namespace membership is determined when the\nprocess is created and cannot be changed thereafter.  Among other things, this means that the\nparental relationship between processes mirrors the parental relationship between  PID  name‐\nspaces:  the  parent of a process is either in the same namespace or resides in the immediate\nparent PID namespace.\n\nA process may call unshare(2) with the CLONENEWPID flag only once.  After it  has  performed\nthis operation, its /proc/pid/ns/pidforchildren symbolic link will be empty until the first\nchild is created in the namespace.\n"
                },
                {
                    "name": "Adoption of orphaned children",
                    "content": "When  a  child  process  becomes  orphaned, it is reparented to the \"init\" process in the PID\nnamespace of its parent (unless one of the  nearer  ancestors  of  the  parent  employed  the\nprctl(2)  PRSETCHILDSUBREAPER  command to mark itself as the reaper of orphaned descendant\nprocesses).  Note that because of the setns(2) and unshare(2) semantics described above, this\nmay be the \"init\" process in the PID namespace that is the parent of the  child's  PID  name‐\nspace, rather than the \"init\" process in the child's own PID namespace.\n\nCompatibility of CLONENEWPID with other CLONE* flags\nIn  current versions of Linux, CLONENEWPID can't be combined with CLONETHREAD.  Threads are\nrequired to be in the same PID namespace such that the threads in a process can send  signals\nto  each other.  Similarly, it must be possible to see all of the threads of a process in the\nproc(5) filesystem.  Additionally, if two threads  were  in  different  PID  namespaces,  the\nprocess ID of the process sending a signal could not be meaningfully encoded when a signal is\nsent  (see  the  description  of the siginfot type in sigaction(2)).  Since this is computed\nwhen a signal is enqueued, a signal queue shared by  processes  in  multiple  PID  namespaces\nwould defeat that.\n\nIn  earlier versions of Linux, CLONENEWPID was additionally disallowed (failing with the er‐\nror EINVAL) in combination with CLONESIGHAND (before Linux 4.3) as well as CLONEVM  (before\nLinux  3.12).   The  changes  that lifted these restrictions have also been ported to earlier\nstable kernels.\n"
                },
                {
                    "name": "/proc and PID namespaces",
                    "content": "A /proc filesystem shows (in the /proc/pid directories) only processes  visible  in  the  PID\nnamespace  of  the  process  that performed the mount, even if the /proc filesystem is viewed\nfrom processes in other namespaces.\n\nAfter creating a new PID namespace, it is useful for the child to change its  root  directory\nand  mount  a  new procfs instance at /proc so that tools such as ps(1) work correctly.  If a\nnew mount namespace is simultaneously created by including CLONENEWNS in the flags  argument\nof clone(2) or unshare(2), then it isn't necessary to change the root directory: a new procfs\ninstance can be mounted directly over /proc.\n\nFrom a shell, the command to mount /proc is:\n\n$ mount -t proc proc /proc\n\nCalling  readlink(2)  on  the  path /proc/self yields the process ID of the caller in the PID\nnamespace of the procfs mount (i.e., the PID  namespace  of  the  process  that  mounted  the\nprocfs).  This can be useful for introspection purposes, when a process wants to discover its\nPID in other namespaces.\n"
                },
                {
                    "name": "/proc files",
                    "content": "/proc/sys/kernel/nslastpid (since Linux 3.3)\nThis  file (which is virtualized per PID namespace) displays the last PID that was al‐\nlocated in this PID namespace.  When the next PID is allocated, the kernel will search\nfor the lowest unallocated PID that is greater than this value, and when this file  is\nsubsequently read it will show that PID.\n\nThis  file  is  writable  by a process that has the CAPSYSADMIN or (since Linux 5.9)\nCAPCHECKPOINTRESTORE capability inside the user namespace that owns  the  PID  name‐\nspace.   This  makes  it  possible  to determine the PID that is allocated to the next\nprocess that is created inside this PID namespace.\n"
                },
                {
                    "name": "Miscellaneous",
                    "content": "When a process ID is passed over a UNIX domain socket to a process in a different  PID  name‐\nspace  (see  the description of SCMCREDENTIALS in unix(7)), it is translated into the corre‐\nsponding PID value in the receiving process's PID namespace.\n"
                }
            ]
        },
        "STANDARDS": {
            "content": "Linux.\n",
            "subsections": []
        },
        "EXAMPLES": {
            "content": "See usernamespaces(7).\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "clone(2),  reboot(2),  setns(2),  unshare(2),   proc(5),   capabilities(7),   credentials(7),\nmountnamespaces(7), namespaces(7), usernamespaces(7), switchroot(8)\n\nLinux man-pages 6.7                          2023-10-31                            pidnamespaces(7)",
            "subsections": []
        }
    },
    "summary": "pidnamespaces - overview of Linux PID namespaces",
    "flags": [],
    "examples": [
        "See usernamespaces(7)."
    ],
    "see_also": [
        {
            "name": "clone",
            "section": "2",
            "url": "https://www.chedong.com/phpMan.php/man/clone/2/json"
        },
        {
            "name": "reboot",
            "section": "2",
            "url": "https://www.chedong.com/phpMan.php/man/reboot/2/json"
        },
        {
            "name": "setns",
            "section": "2",
            "url": "https://www.chedong.com/phpMan.php/man/setns/2/json"
        },
        {
            "name": "unshare",
            "section": "2",
            "url": "https://www.chedong.com/phpMan.php/man/unshare/2/json"
        },
        {
            "name": "proc",
            "section": "5",
            "url": "https://www.chedong.com/phpMan.php/man/proc/5/json"
        },
        {
            "name": "capabilities",
            "section": "7",
            "url": "https://www.chedong.com/phpMan.php/man/capabilities/7/json"
        },
        {
            "name": "credentials",
            "section": "7",
            "url": "https://www.chedong.com/phpMan.php/man/credentials/7/json"
        },
        {
            "name": "mountnamespaces",
            "section": "7",
            "url": "https://www.chedong.com/phpMan.php/man/mountnamespaces/7/json"
        },
        {
            "name": "namespaces",
            "section": "7",
            "url": "https://www.chedong.com/phpMan.php/man/namespaces/7/json"
        },
        {
            "name": "usernamespaces",
            "section": "7",
            "url": "https://www.chedong.com/phpMan.php/man/usernamespaces/7/json"
        },
        {
            "name": "switchroot",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/switchroot/8/json"
        }
    ]
}