1 .\" Copyright (c) 1992 Drew Eckhardt <drew@cs.colorado.edu>, March 28, 1992
2 .\" and Copyright (c) Michael Kerrisk, 2001, 2002, 2005, 2013
4 .\" %%%LICENSE_START(GPL_NOVERSION_ONELINE)
5 .\" May be distributed under the GNU General Public License.
8 .\" Modified by Michael Haardt <michael@moria.de>
9 .\" Modified 24 Jul 1993 by Rik Faith <faith@cs.unc.edu>
10 .\" Modified 21 Aug 1994 by Michael Chastain <mec@shell.portal.com>:
11 .\" New man page (copied from 'fork.2').
12 .\" Modified 10 June 1995 by Andries Brouwer <aeb@cwi.nl>
13 .\" Modified 25 April 1998 by Xavier Leroy <Xavier.Leroy@inria.fr>
14 .\" Modified 26 Jun 2001 by Michael Kerrisk
15 .\" Mostly upgraded to 2.4.x
16 .\" Added prototype for sys_clone() plus description
17 .\" Added CLONE_THREAD with a brief description of thread groups
18 .\" Added CLONE_PARENT and revised entire page remove ambiguity
19 .\" between "calling process" and "parent process"
20 .\" Added CLONE_PTRACE and CLONE_VFORK
21 .\" Added EPERM and EINVAL error codes
22 .\" Renamed "__clone" to "clone" (which is the prototype in <sched.h>)
23 .\" various other minor tidy ups and clarifications.
24 .\" Modified 26 Jun 2001 by Michael Kerrisk <mtk.manpages@gmail.com>
25 .\" Updated notes for 2.4.7+ behavior of CLONE_THREAD
26 .\" Modified 15 Oct 2002 by Michael Kerrisk <mtk.manpages@gmail.com>
27 .\" Added description for CLONE_NEWNS, which was added in 2.4.19
28 .\" Slightly rephrased, aeb.
29 .\" Modified 1 Feb 2003 - added CLONE_SIGHAND restriction, aeb.
30 .\" Modified 1 Jan 2004 - various updates, aeb
31 .\" Modified 2004-09-10 - added CLONE_PARENT_SETTID etc. - aeb.
32 .\" 2005-04-12, mtk, noted the PID caching behavior of NPTL's getpid()
33 .\" wrapper under BUGS.
34 .\" 2005-05-10, mtk, added CLONE_SYSVSEM, CLONE_UNTRACED, CLONE_STOPPED.
35 .\" 2005-05-17, mtk, Substantially enhanced discussion of CLONE_THREAD.
36 .\" 2008-11-18, mtk, order CLONE_* flags alphabetically
37 .\" 2008-11-18, mtk, document CLONE_NEWPID
38 .\" 2008-11-19, mtk, document CLONE_NEWUTS
39 .\" 2008-11-19, mtk, document CLONE_NEWIPC
40 .\" 2008-11-19, Jens Axboe, mtk, document CLONE_IO
42 .\" FIXME Document CLONE_NEWUSER, which is new in 2.6.23
43 .\" (also supported for unshare()?)
45 .TH CLONE 2 2013-01-01 "Linux" "Linux Programmer's Manual"
47 clone, __clone2 \- create a child process
50 .BR "#define _GNU_SOURCE" " /* See feature_test_macros(7) */"
51 .\" Actually _BSD_SOURCE || _SVID_SOURCE
52 .\" FIXME See http://sources.redhat.com/bugzilla/show_bug.cgi?id=4749
55 .BI "int clone(int (*" "fn" ")(void *), void *" child_stack ,
56 .BI " int " flags ", void *" "arg" ", ... "
57 .BI " /* pid_t *" ptid ", struct user_desc *" tls \
58 ", pid_t *" ctid " */ );"
62 creates a new process, in a manner similar to
64 It is actually a library function layered on top of the underlying
66 system call, hereinafter referred to as
70 is given toward the end of this page.
75 allow the child process to share parts of its execution context with
76 the calling process, such as the memory space, the table of file
77 descriptors, and the table of signal handlers.
78 (Note that on this manual
79 page, "calling process" normally corresponds to "parent process".
80 But see the description of
86 is to implement threads: multiple threads of control in a program that
87 run concurrently in a shared memory space.
89 When the child process is created with
91 it executes the function
95 where execution continues in the child from the point
101 argument is a pointer to a function that is called by the child
102 process at the beginning of its execution.
105 argument is passed to the
111 function application returns, the child process terminates.
112 The integer returned by
114 is the exit code for the child process.
115 The child process may also terminate explicitly by calling
117 or after receiving a fatal signal.
121 argument specifies the location of the stack used by the child process.
122 Since the child and calling process may share memory,
123 it is not possible for the child process to execute in the
124 same stack as the calling process.
125 The calling process must therefore
126 set up memory space for the child stack and pass a pointer to this
129 Stacks grow downward on all processors that run Linux
130 (except the HP PA processors), so
132 usually points to the topmost address of the memory space set up for
137 contains the number of the
138 .I "termination signal"
139 sent to the parent when the child dies.
140 If this signal is specified as anything other than
142 then the parent process must specify the
146 options when waiting for the child with
148 If no signal is specified, then the parent process is not signaled
149 when the child terminates.
152 may also be bitwise-or'ed with zero or more of the following constants,
153 in order to specify what is shared between the calling process
154 and the child process:
156 .BR CLONE_CHILD_CLEARTID " (since Linux 2.5.49)"
157 Erase child thread ID at location
159 in child memory when the child exits, and do a wakeup on the futex
161 The address involved may be changed by the
162 .BR set_tid_address (2)
164 This is used by threading libraries.
166 .BR CLONE_CHILD_SETTID " (since Linux 2.5.49)"
167 Store child thread ID at location
171 .BR CLONE_FILES " (since Linux 2.0)"
174 is set, the calling process and the child process share the same file
176 Any file descriptor created by the calling process or by the child
177 process is also valid in the other process.
178 Similarly, if one of the processes closes a file descriptor,
179 or changes its associated flags (using the
182 operation), the other process is also affected.
186 is not set, the child process inherits a copy of all file descriptors
187 opened in the calling process at the time of
189 (The duplicated file descriptors in the child refer to the
190 same open file descriptions (see
192 as the corresponding file descriptors in the calling process.)
193 Subsequent operations that open or close file descriptors,
194 or change file descriptor flags,
195 performed by either the calling
196 process or the child process do not affect the other process.
198 .BR CLONE_FS " (since Linux 2.0)"
201 is set, the caller and the child process share the same file system
203 This includes the root of the file system, the current
204 working directory, and the umask.
210 performed by the calling process or the child process also affects the
215 is not set, the child process works on a copy of the file system
216 information of the calling process at the time of the
223 performed later by one of the processes do not affect the other process.
225 .BR CLONE_IO " (since Linux 2.6.25)"
228 is set, then the new process shares an I/O context with
230 If this flag is not set, then (as with
232 the new process has its own I/O context.
234 .\" The following based on text from Jens Axboe
235 The I/O context is the I/O scope of the disk scheduler (i.e,
236 what the I/O scheduler uses to model scheduling of a process's I/O).
237 If processes share the same I/O context,
238 they are treated as one by the I/O scheduler.
239 As a consequence, they get to share disk time.
240 For some I/O schedulers,
241 .\" the anticipatory and CFQ scheduler
242 if two processes share an I/O context,
243 they will be allowed to interleave their disk access.
244 If several threads are doing I/O on behalf of the same process
246 for instance), they should employ
248 to get better I/O performance.
251 If the kernel is not configured with the
253 option, this flag is a no-op.
255 .BR CLONE_NEWIPC " (since Linux 2.6.19)"
258 is set, then create the process in a new IPC namespace.
259 If this flag is not set, then (as with
261 the process is created in the same IPC namespace as
263 This flag is intended for the implementation of containers.
265 An IPC namespace provides an isolated view of System V IPC objects (see
267 and (since Linux 2.6.30)
268 .\" commit 7eafd7c74c3f2e67c27621b987b28397110d643f
269 .\" https://lwn.net/Articles/312232/
272 .BR mq_overview (7)).
273 The common characteristic of these IPC mechanisms is that IPC
274 objects are identified by mechanisms other than filesystem
277 Objects created in an IPC namespace are visible to all other processes
278 that are members of that namespace,
279 but are not visible to processes in other IPC namespaces.
281 When an IPC namespace is destroyed
282 (i.e., when the last process that is a member of the namespace terminates),
283 all IPC objects in the namespace are automatically destroyed.
285 Use of this flag requires: a kernel configured with the
289 options and that the process be privileged
290 .RB ( CAP_SYS_ADMIN ).
291 This flag can't be specified in conjunction with
294 .BR CLONE_NEWNET " (since Linux 2.6.24)"
295 .\" FIXME Check when the implementation was completed
296 (The implementation of this flag was only completed
297 by about kernel version 2.6.29.)
301 is set, then create the process in a new network namespace.
302 If this flag is not set, then (as with
304 the process is created in the same network namespace as
306 This flag is intended for the implementation of containers.
308 A network namespace provides an isolated view of the networking stack
309 (network device interfaces, IPv4 and IPv6 protocol stacks,
310 IP routing tables, firewall rules, the
314 directory trees, sockets, etc.).
315 A physical network device can live in exactly one
317 A virtual network device ("veth") pair provides a pipe-like abstraction
318 .\" FIXME Add pointer to veth(4) page when it is eventually completed
319 that can be used to create tunnels between network namespaces,
320 and can be used to create a bridge to a physical network device
321 in another namespace.
323 When a network namespace is freed
324 (i.e., when the last process in the namespace terminates),
325 its physical network devices are moved back to the
326 initial network namespace (not to the parent of the process).
328 Use of this flag requires: a kernel configured with the
330 option and that the process be privileged
331 .RB ( CAP_SYS_ADMIN ).
333 .BR CLONE_NEWNS " (since Linux 2.4.19)"
334 Start the child in a new mount namespace.
336 Every process lives in a mount namespace.
339 of a process is the data (the set of mounts) describing the file hierarchy
340 as seen by that process.
347 flag is not set, the child lives in the same mount
348 namespace as the parent.
353 change the mount namespace of the calling process, and hence affect
354 all processes that live in the same namespace, but do not affect
355 processes in a different mount namespace.
361 flag is set, the cloned child is started in a new mount namespace,
362 initialized with a copy of the namespace of the parent.
364 Only a privileged process (one having the \fBCAP_SYS_ADMIN\fP capability)
368 It is not permitted to specify both
376 .BR CLONE_NEWPID " (since Linux 2.6.24)"
377 .\" This explanation draws a lot of details from
378 .\" http://lwn.net/Articles/259217/
379 .\" Authors: Pavel Emelyanov <xemul@openvz.org>
380 .\" and Kir Kolyshkin <kir@openvz.org>
382 .\" The primary kernel commit is 30e49c263e36341b60b735cbef5ca37912549264
383 .\" Author: Pavel Emelyanov <xemul@openvz.org>
386 is set, then create the process in a new PID namespace.
387 If this flag is not set, then (as with
389 the process is created in the same PID namespace as
391 This flag is intended for the implementation of containers.
393 A PID namespace provides an isolated environment for PIDs:
394 PIDs in a new namespace start at 1,
395 somewhat like a standalone system, and calls to
400 will produce processes with PIDs that are unique within the namespace.
402 The first process created in a new namespace
403 (i.e., the process created using the
405 flag) has the PID 1, and is the "init" process for the namespace.
406 Children that are orphaned within the namespace will be reparented
407 to this process rather than
409 Unlike the traditional
411 process, the "init" process of a PID namespace can terminate,
412 and if it does, all of the processes in the namespace are terminated.
414 PID namespaces form a hierarchy.
415 When a new PID namespace is created,
416 the processes in that namespace are visible
417 in the PID namespace of the process that created the new namespace;
418 analogously, if the parent PID namespace is itself
419 the child of another PID namespace,
420 then processes in the child and parent PID namespaces will both be
421 visible in the grandparent PID namespace.
422 Conversely, the processes in the "child" PID namespace do not see
423 the processes in the parent namespace.
424 The existence of a namespace hierarchy means that each process
425 may now have multiple PIDs:
426 one for each namespace in which it is visible;
427 each of these PIDs is unique within the corresponding namespace.
430 always returns the PID associated with the namespace in which
433 After creating the new namespace,
434 it is useful for the child to change its root directory
435 and mount a new procfs instance at
437 so that tools such as
440 .\" mount -t proc proc /proc
445 then it isn't necessary to change the root directory:
446 a new procfs instance can be mounted directly over
449 Use of this flag requires: a kernel configured with the
451 option and that the process be privileged
452 .RB ( CAP_SYS_ADMIN ).
453 This flag can't be specified in conjunction with
456 .BR CLONE_NEWUTS " (since Linux 2.6.19)"
459 is set, then create the process in a new UTS namespace,
460 whose identifiers are initialized by duplicating the identifiers
461 from the UTS namespace of the calling process.
462 If this flag is not set, then (as with
464 the process is created in the same UTS namespace as
466 This flag is intended for the implementation of containers.
468 A UTS namespace is the set of identifiers returned by
470 among these, the domain name and the host name can be modified by
471 .BR setdomainname (2)
476 Changes made to the identifiers in a UTS namespace
477 are visible to all other processes in the same namespace,
478 but are not visible to processes in other UTS namespaces.
480 Use of this flag requires: a kernel configured with the
482 option and that the process be privileged
483 .RB ( CAP_SYS_ADMIN ).
485 .BR CLONE_PARENT " (since Linux 2.3.12)"
488 is set, then the parent of the new child (as returned by
490 will be the same as that of the calling process.
494 is not set, then (as with
496 the child's parent is the calling process.
498 Note that it is the parent process, as returned by
500 which is signaled when the child terminates, so that
503 is set, then the parent of the calling process, rather than the
504 calling process itself, will be signaled.
506 .BR CLONE_PARENT_SETTID " (since Linux 2.5.49)"
507 Store child thread ID at location
509 in parent and child memory.
510 (In Linux 2.5.32-2.5.48 there was a flag
514 .BR CLONE_PID " (obsolete)"
517 is set, the child process is created with the same process ID as
519 This is good for hacking the system, but otherwise
521 Since 2.3.21 this flag can be
522 specified only by the system boot process (PID 0).
523 It disappeared in Linux 2.5.16.
525 .BR CLONE_PTRACE " (since Linux 2.2)"
528 is specified, and the calling process is being traced,
529 then trace the child also (see
532 .BR CLONE_SETTLS " (since Linux 2.5.32)"
535 argument is the new TLS (Thread Local Storage) descriptor.
537 .BR set_thread_area (2).)
539 .BR CLONE_SIGHAND " (since Linux 2.0)"
542 is set, the calling process and the child process share the same table of
544 If the calling process or child process calls
546 to change the behavior associated with a signal, the behavior is
547 changed in the other process as well.
548 However, the calling process and child
549 processes still have distinct signal masks and sets of pending
551 So, one of them may block or unblock some signals using
553 without affecting the other process.
557 is not set, the child process inherits a copy of the signal handlers
558 of the calling process at the time
563 performed later by one of the processes have no effect on the other
566 Since Linux 2.6.0-test6,
574 .BR CLONE_STOPPED " (since Linux 2.6.0-test2)"
577 is set, then the child is initially stopped (as though it was sent a
579 signal), and must be resumed by sending it a
585 from Linux 2.6.25 onward,
588 altogether in Linux 2.6.38.
589 .\" glibc 2.8 removed this defn from bits/sched.h
591 .BR CLONE_SYSVSEM " (since Linux 2.5.10)"
594 is set, then the child and the calling process share
595 a single list of System V semaphore undo values (see
597 If this flag is not set, then the child has a separate undo list,
598 which is initially empty.
600 .BR CLONE_THREAD " (since Linux 2.4.0-test8)"
603 is set, the child is placed in the same thread group as the calling process.
604 To make the remainder of the discussion of
606 more readable, the term "thread" is used to refer to the
607 processes within a thread group.
609 Thread groups were a feature added in Linux 2.4 to support the
610 POSIX threads notion of a set of threads that share a single PID.
611 Internally, this shared PID is the so-called
612 thread group identifier (TGID) for the thread group.
613 Since Linux 2.4, calls to
615 return the TGID of the caller.
617 The threads within a group can be distinguished by their (system-wide)
618 unique thread IDs (TID).
619 A new thread's TID is available as the function result
620 returned to the caller of
622 and a thread can obtain
626 When a call is made to
630 then the resulting thread is placed in a new thread group
631 whose TGID is the same as the thread's TID.
634 of the new thread group.
636 A new thread created with
638 has the same parent process as the caller of
644 return the same value for all of the threads in a thread group.
647 thread terminates, the thread that created it using
651 (or other termination) signal;
652 nor can the status of such a thread be obtained
655 (The thread is said to be
658 After all of the threads in a thread group terminate
659 the parent process of the thread group is sent a
661 (or other termination) signal.
663 If any of the threads in a thread group performs an
665 then all threads other than the thread group leader are terminated,
666 and the new program is executed in the thread group leader.
668 If one of the threads in a thread group creates a child using
670 then any thread in the group can
682 Signals may be sent to a thread group as a whole (i.e., a TGID) using
684 or to a specific thread (i.e., TID) using
687 Signal dispositions and actions are process-wide:
688 if an unhandled signal is delivered to a thread, then
689 it will affect (terminate, stop, continue, be ignored in)
690 all members of the thread group.
692 Each thread has its own signal mask, as set by
694 but signals can be pending either: for the whole process
695 (i.e., deliverable to any member of the thread group),
698 or for an individual thread, when sent with
702 returns a signal set that is the union of the signals pending for the
703 whole process and the signals that are pending for the calling thread.
707 is used to send a signal to a thread group,
708 and the thread group has installed a handler for the signal, then
709 the handler will be invoked in exactly one, arbitrarily selected
710 member of the thread group that has not blocked the signal.
711 If multiple threads in a group are waiting to accept the same signal using
713 the kernel will arbitrarily select one of these threads
714 to receive a signal sent using
717 .BR CLONE_UNTRACED " (since Linux 2.5.46)"
720 is specified, then a tracing process cannot force
722 on this child process.
724 .BR CLONE_VFORK " (since Linux 2.2)"
727 is set, the execution of the calling process is suspended
728 until the child releases its virtual memory
729 resources via a call to
738 is not set then both the calling process and the child are schedulable
739 after the call, and an application should not rely on execution occurring
740 in any particular order.
742 .BR CLONE_VM " (since Linux 2.0)"
745 is set, the calling process and the child process run in the same memory
747 In particular, memory writes performed by the calling process
748 or by the child process are also visible in the other process.
749 Moreover, any memory mapping or unmapping performed with
753 by the child or calling process also affects the other process.
757 is not set, the child process runs in a separate copy of the memory
758 space of the calling process at the time of
760 Memory writes or file mappings/unmappings performed by one of the
761 processes do not affect the other, as with
766 system call corresponds more closely to
768 in that execution in the child continues from the point of the
776 wrapper function are omitted.
777 Furthermore, the argument order changes.
778 The raw system call interface is roughly:
782 .BI "long clone(unsigned long " flags ", void *" child_stack ,
783 .BI " void *" ptid ", void *" ctid ,
784 .BI " struct pt_regs *" regs );
788 Another difference for
792 argument may be zero, in which case copy-on-write semantics ensure that the
793 child gets separate copies of stack pages when either process modifies
795 In this case, for correct operation, the
797 option should not be specified.
798 .SS Linux 2.4 and earlier
799 In Linux 2.4 and earlier,
801 does not take arguments
807 .\" gettid(2) returns current->pid;
808 .\" getpid(2) returns current->tgid;
809 On success, the thread ID of the child process is returned
810 in the caller's thread of execution.
811 On failure, \-1 is returned
812 in the caller's context, no child process will be created, and
814 will be set appropriately.
818 Too many processes are already running.
825 (Since Linux 2.6.0-test6.)
832 (Since Linux 2.5.35.)
836 .\" .B CLONE_DETACHED
840 .\" (Since Linux 2.6.0-test6.)
869 when a zero value is specified for
876 but the kernel was not configured with the
886 but the kernel was not configured with the
894 but the kernel was not configured with the
902 but the kernel was not configured with the
907 Cannot allocate sufficient memory to allocate a task structure for the
908 child, or to copy those parts of the caller's context that need to be
918 was specified by an unprivileged process (process without \fBCAP_SYS_ADMIN\fP).
922 was specified by a process other than process 0.
924 There is no entry for
929 as described in this manual page.
935 calls are Linux-specific and should not be used in programs
936 intended to be portable.
938 In the kernel 2.4.x series,
940 generally does not make the parent of the new thread the same
941 as the parent of the calling process.
942 However, for kernel versions 2.4.7 to 2.4.18 the
946 flag (as in kernel 2.6).
948 For a while there was
950 (introduced in 2.5.32):
951 parent wants no child-exit signal.
952 In 2.6.2 the need to give this
956 This flag is still defined, but has no effect.
960 should not be called through vsyscall, but directly through
963 On ia64, a different system call is used:
966 .BI "int __clone2(int (*" "fn" ")(void *), "
967 .BI " void *" child_stack_base ", size_t " stack_size ,
968 .BI " int " flags ", void *" "arg" ", ... "
969 .BI " /* pid_t *" ptid ", struct user_desc *" tls \
970 ", pid_t *" ctid " */ );"
975 system call operates in the same way as
979 points to the lowest address of the child's stack area,
982 specifies the size of the stack pointed to by
983 .IR child_stack_base .
985 Versions of the GNU C library that include the NPTL threading library
986 contain a wrapper function for
988 that performs caching of PIDs.
989 This caching relies on support in the glibc wrapper for
991 but as currently implemented,
992 the cache may not be up to date in some circumstances.
994 if a signal is delivered to the child immediately after the
998 in a handler for the signal may return the PID
999 of the calling process ("the parent"),
1000 if the clone wrapper has not yet had a chance to update the PID
1002 (This discussion ignores the case where the child was created using
1007 return the same value in the child and in the process that called
1009 since the caller and the child are in the same thread group.
1010 The stale-cache problem also does not occur if the
1014 To get the truth, it may be necessary to use code such as the following:
1017 #include <syscall.h>
1021 mypid = syscall(SYS_getpid);
1023 .\" See also the following bug reports
1024 .\" https://bugzilla.redhat.com/show_bug.cgi?id=417521
1025 .\" http://sourceware.org/bugzilla/show_bug.cgi?id=6910
1027 .SS Create a child that executes in a separate UTS namespace
1028 The following program demonstrates the use of
1030 to create a child process that executes in a separate UTS namespace.
1031 The child changes the hostname in its UTS namespace.
1032 Both parent and child then display the system hostname,
1033 making it possible to see that the hostname
1034 differs in the UTS namespaces of the parent and child.
1035 For an example of the use of this program, see
1040 #include <sys/wait.h>
1041 #include <sys/utsname.h>
1048 #define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \\
1051 static int /* Start function for cloned child */
1052 childFunc(void *arg)
1056 /* Change hostname in UTS namespace of child */
1058 if (sethostname(arg, strlen(arg)) == \-1)
1059 errExit("sethostname");
1061 /* Retrieve and display hostname */
1063 if (uname(&uts) == \-1)
1065 printf("uts.nodename in child: %s\\n", uts.nodename);
1067 /* Keep the namespace open for a while, by sleeping.
1068 This allows some experimentation\-\-for example, another
1069 process might join the namespace. */
1073 return 0; /* Child terminates now */
1076 #define STACK_SIZE (1024 * 1024) /* Stack size for cloned child */
1079 main(int argc, char *argv[])
1081 char *stack; /* Start of stack buffer */
1082 char *stackTop; /* End of stack buffer */
1087 fprintf(stderr, "Usage: %s <child\-hostname>\\n", argv[0]);
1091 /* Allocate stack for child */
1093 stack = malloc(STACK_SIZE);
1096 stackTop = stack + STACK_SIZE; /* Assume stack grows downward */
1098 /* Create child that has its own UTS namespace;
1099 child commences execution in childFunc() */
1101 pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]);
1104 printf("clone() returned %ld\\n", (long) pid);
1106 /* Parent falls through to here */
1108 sleep(1); /* Give child time to change its hostname */
1110 /* Display hostname in parent\(aqs UTS namespace. This will be
1111 different from hostname in child\(aqs UTS namespace. */
1113 if (uname(&uts) == \-1)
1115 printf("uts.nodename in parent: %s\\n", uts.nodename);
1117 if (waitpid(pid, NULL, 0) == \-1) /* Wait for child */
1119 printf("child has terminated\\n");
1130 .BR set_thread_area (2),
1131 .BR set_tid_address (2),
1136 .BR capabilities (7),