{
    "mode": "man",
    "parameter": "pid_namespaces",
    "section": "7",
    "url": "https://www.chedong.com/phpMan.php/man/pid_namespaces/7/json",
    "generated": "2026-06-04T04:50:52Z",
    "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  pro‐\ncesses  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,  pro‐\ncesses may not enter any ancestor namespaces (parent, grandparent, etc.).  Changing PID name‐\nspaces 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\nnot,  however, change the PID namespace of the calling process, because doing so would change\nthe caller's idea of its own PID (as reported by getpid()), which would break  many  applica‐\ntions and 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  processes  in\nthe  proc(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"
                }
            ]
        },
        "CONFORMING TO": {
            "content": "Namespaces are a Linux-specific feature.\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",
            "subsections": []
        },
        "COLOPHON": {
            "content": "This page is part of release 5.10 of the Linux  man-pages  project.   A  description  of  the\nproject,  information about reporting bugs, and the latest version of this page, can be found\nat https://www.kernel.org/doc/man-pages/.\n\n\n\nLinux                                        2020-11-01                            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"
        }
    ]
}