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 .TH CLONE 2 2016-07-17 "Linux" "Linux Programmer's Manual"
44 clone, __clone2 \- create a child process
47 /* Prototype for the glibc wrapper function */
49 .B #define _GNU_SOURCE
52 .BI "int clone(int (*" "fn" ")(void *), void *" child_stack ,
53 .BI " int " flags ", void *" "arg" ", ... "
54 .BI " /* pid_t *" ptid ", void *" newtls \
55 ", pid_t *" ctid " */ );"
57 /* For the prototype of the raw system call, see NOTES */
61 creates a new process, in a manner similar to
64 This page describes both the glibc
66 wrapper function and the underlying system call on which it is based.
67 The main text describes the wrapper function;
68 the differences for the raw system call
69 are described toward the end of this page.
74 allows the child process to share parts of its execution context with
75 the calling process, such as the memory space, the table of file
76 descriptors, and the table of signal handlers.
77 (Note that on this manual
78 page, "calling process" normally corresponds to "parent process".
79 But see the description of
85 is to implement threads: multiple threads of control in a program that
86 run concurrently in a shared memory space.
88 When the child process is created with
90 it executes the function
94 where execution continues in the child from the point
100 argument is a pointer to a function that is called by the child
101 process at the beginning of its execution.
104 argument is passed to the
110 function application returns, the child process terminates.
111 The integer returned by
113 is the exit code for the child process.
114 The child process may also terminate explicitly by calling
116 or after receiving a fatal signal.
120 argument specifies the location of the stack used by the child process.
121 Since the child and calling process may share memory,
122 it is not possible for the child process to execute in the
123 same stack as the calling process.
124 The calling process must therefore
125 set up memory space for the child stack and pass a pointer to this
128 Stacks grow downward on all processors that run Linux
129 (except the HP PA processors), so
131 usually points to the topmost address of the memory space set up for
136 contains the number of the
137 .I "termination signal"
138 sent to the parent when the child dies.
139 If this signal is specified as anything other than
141 then the parent process must specify the
145 options when waiting for the child with
147 If no signal is specified, then the parent process is not signaled
148 when the child terminates.
151 may also be bitwise-or'ed with zero or more of the following constants,
152 in order to specify what is shared between the calling process
153 and the child process:
155 .BR CLONE_CHILD_CLEARTID " (since Linux 2.5.49)"
156 Clear (zero) the child thread ID at the location
158 in child memory when the child exits, and do a wakeup on the futex
160 The address involved may be changed by the
161 .BR set_tid_address (2)
163 This is used by threading libraries.
165 .BR CLONE_CHILD_SETTID " (since Linux 2.5.49)"
166 Store the child thread ID at the location
168 in the child's memory.
169 The store operation completes before
171 returns control to user space.
173 .BR CLONE_FILES " (since Linux 2.0)"
176 is set, the calling process and the child process share the same file
178 Any file descriptor created by the calling process or by the child
179 process is also valid in the other process.
180 Similarly, if one of the processes closes a file descriptor,
181 or changes its associated flags (using the
184 operation), the other process is also affected.
185 If a process sharing a file descriptor table calls
187 its file descriptor table is duplicated (unshared).
191 is not set, the child process inherits a copy of all file descriptors
192 opened in the calling process at the time of
194 Subsequent operations that open or close file descriptors,
195 or change file descriptor flags,
196 performed by either the calling
197 process or the child process do not affect the other process.
199 that the duplicated file descriptors in the child refer to the same open file
200 descriptions as the corresponding file descriptors in the calling process,
201 and thus share file offsets and file status flags (see
204 .BR CLONE_FS " (since Linux 2.0)"
207 is set, the caller and the child process share the same filesystem
209 This includes the root of the filesystem, the current
210 working directory, and the umask.
216 performed by the calling process or the child process also affects the
221 is not set, the child process works on a copy of the filesystem
222 information of the calling process at the time of the
229 performed later by one of the processes do not affect the other process.
231 .BR CLONE_IO " (since Linux 2.6.25)"
234 is set, then the new process shares an I/O context with
236 If this flag is not set, then (as with
238 the new process has its own I/O context.
240 .\" The following based on text from Jens Axboe
241 The I/O context is the I/O scope of the disk scheduler (i.e.,
242 what the I/O scheduler uses to model scheduling of a process's I/O).
243 If processes share the same I/O context,
244 they are treated as one by the I/O scheduler.
245 As a consequence, they get to share disk time.
246 For some I/O schedulers,
247 .\" the anticipatory and CFQ scheduler
248 if two processes share an I/O context,
249 they will be allowed to interleave their disk access.
250 If several threads are doing I/O on behalf of the same process
252 for instance), they should employ
254 to get better I/O performance.
257 If the kernel is not configured with the
259 option, this flag is a no-op.
261 .BR CLONE_NEWCGROUP " (since Linux 4.6)"
262 Create the process in a new cgroup namespace.
263 If this flag is not set, then (as with
265 the process is created in the same cgroup namespaces as the calling process.
266 This flag is intended for the implementation of containers.
268 For further information on cgroup namespaces, see
269 .BR cgroup_namespaces (7).
271 Only a privileged process
272 .RB ( CAP_SYS_ADMIN )
274 .BR CLONE_NEWCGROUP .
277 .BR CLONE_NEWIPC " (since Linux 2.6.19)"
280 is set, then create the process in a new IPC namespace.
281 If this flag is not set, then (as with
283 the process is created in the same IPC namespace as
285 This flag is intended for the implementation of containers.
287 An IPC namespace provides an isolated view of System\ V IPC objects (see
289 and (since Linux 2.6.30)
290 .\" commit 7eafd7c74c3f2e67c27621b987b28397110d643f
291 .\" https://lwn.net/Articles/312232/
294 .BR mq_overview (7)).
295 The common characteristic of these IPC mechanisms is that IPC
296 objects are identified by mechanisms other than filesystem
299 Objects created in an IPC namespace are visible to all other processes
300 that are members of that namespace,
301 but are not visible to processes in other IPC namespaces.
303 When an IPC namespace is destroyed
304 (i.e., when the last process that is a member of the namespace terminates),
305 all IPC objects in the namespace are automatically destroyed.
307 Only a privileged process
308 .RB ( CAP_SYS_ADMIN )
311 This flag can't be specified in conjunction with
314 For further information on IPC namespaces, see
317 .BR CLONE_NEWNET " (since Linux 2.6.24)"
318 (The implementation of this flag was completed only
319 by about kernel version 2.6.29.)
323 is set, then create the process in a new network namespace.
324 If this flag is not set, then (as with
326 the process is created in the same network namespace as
328 This flag is intended for the implementation of containers.
330 A network namespace provides an isolated view of the networking stack
331 (network device interfaces, IPv4 and IPv6 protocol stacks,
332 IP routing tables, firewall rules, the
336 directory trees, sockets, etc.).
337 A physical network device can live in exactly one
339 A virtual network device ("veth") pair provides a pipe-like abstraction
340 .\" FIXME . Add pointer to veth(4) page when it is eventually completed
341 that can be used to create tunnels between network namespaces,
342 and can be used to create a bridge to a physical network device
343 in another namespace.
345 When a network namespace is freed
346 (i.e., when the last process in the namespace terminates),
347 its physical network devices are moved back to the
348 initial network namespace (not to the parent of the process).
349 For further information on network namespaces, see
352 Only a privileged process
353 .RB ( CAP_SYS_ADMIN )
357 .BR CLONE_NEWNS " (since Linux 2.4.19)"
360 is set, the cloned child is started in a new mount namespace,
361 initialized with a copy of the namespace of the parent.
364 is not set, the child lives in the same mount
365 namespace as the parent.
367 Only a privileged process
368 .RB ( CAP_SYS_ADMIN )
371 It is not permitted to specify both
375 .\" See https://lwn.net/Articles/543273/
380 For further information on mount namespaces, see
383 .BR mount_namespaces (7).
385 .BR CLONE_NEWPID " (since Linux 2.6.24)"
386 .\" This explanation draws a lot of details from
387 .\" http://lwn.net/Articles/259217/
388 .\" Authors: Pavel Emelyanov <xemul@openvz.org>
389 .\" and Kir Kolyshkin <kir@openvz.org>
391 .\" The primary kernel commit is 30e49c263e36341b60b735cbef5ca37912549264
392 .\" Author: Pavel Emelyanov <xemul@openvz.org>
395 is set, then create the process in a new PID namespace.
396 If this flag is not set, then (as with
398 the process is created in the same PID namespace as
400 This flag is intended for the implementation of containers.
402 For further information on PID namespaces, see
405 .BR pid_namespaces (7).
407 Only a privileged process
408 .RB ( CAP_SYS_ADMIN )
411 This flag can't be specified in conjunction with
417 (This flag first became meaningful for
422 semantics were merged in Linux 3.5,
423 and the final pieces to make the user namespaces completely usable were
424 merged in Linux 3.8.)
428 is set, then create the process in a new user namespace.
429 If this flag is not set, then (as with
431 the process is created in the same user namespace as the calling process.
433 For further information on user namespaces, see
436 .BR user_namespaces (7)
438 Before Linux 3.8, use of
440 required that the caller have three capabilities:
445 .\" Before Linux 2.6.29, it appears that only CAP_SYS_ADMIN was needed
446 Starting with Linux 3.8,
447 no privileges are needed to create a user namespace.
449 This flag can't be specified in conjunction with
453 For security reasons,
454 .\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71
455 .\" https://lwn.net/Articles/543273/
456 .\" The fix actually went into 3.9 and into 3.8.3. However, user namespaces
457 .\" were, for practical purposes, unusable in earlier 3.8.x because of the
458 .\" various filesystems that didn't support userns.
460 cannot be specified in conjunction with
463 For further information on user namespaces, see
464 .BR user_namespaces (7).
466 .BR CLONE_NEWUTS " (since Linux 2.6.19)"
469 is set, then create the process in a new UTS namespace,
470 whose identifiers are initialized by duplicating the identifiers
471 from the UTS namespace of the calling process.
472 If this flag is not set, then (as with
474 the process is created in the same UTS namespace as
476 This flag is intended for the implementation of containers.
478 A UTS namespace is the set of identifiers returned by
480 among these, the domain name and the hostname can be modified by
481 .BR setdomainname (2)
485 Changes made to the identifiers in a UTS namespace
486 are visible to all other processes in the same namespace,
487 but are not visible to processes in other UTS namespaces.
489 Only a privileged process
490 .RB ( CAP_SYS_ADMIN )
494 For further information on UTS namespaces, see
497 .BR CLONE_PARENT " (since Linux 2.3.12)"
500 is set, then the parent of the new child (as returned by
502 will be the same as that of the calling process.
506 is not set, then (as with
508 the child's parent is the calling process.
510 Note that it is the parent process, as returned by
512 which is signaled when the child terminates, so that
515 is set, then the parent of the calling process, rather than the
516 calling process itself, will be signaled.
518 .BR CLONE_PARENT_SETTID " (since Linux 2.5.49)"
519 Store the child thread ID at the location
521 in the parent's memory.
522 (In Linux 2.5.32-2.5.48 there was a flag
525 The store operation completes before
527 returns control to user space.
529 .BR CLONE_PID " (obsolete)"
532 is set, the child process is created with the same process ID as
534 This is good for hacking the system, but otherwise
536 Since 2.3.21 this flag can be
537 specified only by the system boot process (PID 0).
538 It disappeared in Linux 2.5.16.
539 Since then, the kernel silently ignores it without error.
541 .BR CLONE_PTRACE " (since Linux 2.2)"
544 is specified, and the calling process is being traced,
545 then trace the child also (see
548 .BR CLONE_SETTLS " (since Linux 2.5.32)"
549 The TLS (Thread Local Storage) descriptor is set to
552 The interpretation of
554 and the resulting effect is architecture dependent.
558 .IR "struct user_desc *"
560 .BR set_thread_area (2)).
561 On x86_64 it is the new value to be set for the %fs base register
566 On architectures with a dedicated TLS register, it is the new value
569 .BR CLONE_SIGHAND " (since Linux 2.0)"
572 is set, the calling process and the child process share the same table of
574 If the calling process or child process calls
576 to change the behavior associated with a signal, the behavior is
577 changed in the other process as well.
578 However, the calling process and child
579 processes still have distinct signal masks and sets of pending
581 So, one of them may block or unblock some signals using
583 without affecting the other process.
587 is not set, the child process inherits a copy of the signal handlers
588 of the calling process at the time
593 performed later by one of the processes have no effect on the other
596 Since Linux 2.6.0-test6,
604 .BR CLONE_STOPPED " (since Linux 2.6.0-test2)"
607 is set, then the child is initially stopped (as though it was sent a
609 signal), and must be resumed by sending it a
615 from Linux 2.6.25 onward,
618 altogether in Linux 2.6.38.
619 Since then, the kernel silently ignores it without error.
620 .\" glibc 2.8 removed this defn from bits/sched.h
621 Starting with Linux 4.6, the same bit was reused for the
625 .BR CLONE_SYSVSEM " (since Linux 2.5.10)"
628 is set, then the child and the calling process share
629 a single list of System V semaphore adjustment
633 In this case, the shared list accumulates
635 values across all processes sharing the list,
636 and semaphore adjustments are performed only when the last process
637 that is sharing the list terminates (or ceases sharing the list using
639 If this flag is not set, then the child has a separate
641 list that is initially empty.
643 .BR CLONE_THREAD " (since Linux 2.4.0-test8)"
646 is set, the child is placed in the same thread group as the calling process.
647 To make the remainder of the discussion of
649 more readable, the term "thread" is used to refer to the
650 processes within a thread group.
652 Thread groups were a feature added in Linux 2.4 to support the
653 POSIX threads notion of a set of threads that share a single PID.
654 Internally, this shared PID is the so-called
655 thread group identifier (TGID) for the thread group.
656 Since Linux 2.4, calls to
658 return the TGID of the caller.
660 The threads within a group can be distinguished by their (system-wide)
661 unique thread IDs (TID).
662 A new thread's TID is available as the function result
663 returned to the caller of
665 and a thread can obtain
669 When a call is made to
673 then the resulting thread is placed in a new thread group
674 whose TGID is the same as the thread's TID.
677 of the new thread group.
679 A new thread created with
681 has the same parent process as the caller of
687 return the same value for all of the threads in a thread group.
690 thread terminates, the thread that created it using
694 (or other termination) signal;
695 nor can the status of such a thread be obtained
698 (The thread is said to be
701 After all of the threads in a thread group terminate
702 the parent process of the thread group is sent a
704 (or other termination) signal.
706 If any of the threads in a thread group performs an
708 then all threads other than the thread group leader are terminated,
709 and the new program is executed in the thread group leader.
711 If one of the threads in a thread group creates a child using
713 then any thread in the group can
724 (and note that, since Linux 2.6.0-test6,
730 Signals may be sent to a thread group as a whole (i.e., a TGID) using
732 or to a specific thread (i.e., TID) using
735 Signal dispositions and actions are process-wide:
736 if an unhandled signal is delivered to a thread, then
737 it will affect (terminate, stop, continue, be ignored in)
738 all members of the thread group.
740 Each thread has its own signal mask, as set by
742 but signals can be pending either: for the whole process
743 (i.e., deliverable to any member of the thread group),
746 or for an individual thread, when sent with
750 returns a signal set that is the union of the signals pending for the
751 whole process and the signals that are pending for the calling thread.
755 is used to send a signal to a thread group,
756 and the thread group has installed a handler for the signal, then
757 the handler will be invoked in exactly one, arbitrarily selected
758 member of the thread group that has not blocked the signal.
759 If multiple threads in a group are waiting to accept the same signal using
761 the kernel will arbitrarily select one of these threads
762 to receive a signal sent using
765 .BR CLONE_UNTRACED " (since Linux 2.5.46)"
768 is specified, then a tracing process cannot force
770 on this child process.
772 .BR CLONE_VFORK " (since Linux 2.2)"
775 is set, the execution of the calling process is suspended
776 until the child releases its virtual memory
777 resources via a call to
786 is not set, then both the calling process and the child are schedulable
787 after the call, and an application should not rely on execution occurring
788 in any particular order.
790 .BR CLONE_VM " (since Linux 2.0)"
793 is set, the calling process and the child process run in the same memory
795 In particular, memory writes performed by the calling process
796 or by the child process are also visible in the other process.
797 Moreover, any memory mapping or unmapping performed with
801 by the child or calling process also affects the other process.
805 is not set, the child process runs in a separate copy of the memory
806 space of the calling process at the time of
808 Memory writes or file mappings/unmappings performed by one of the
809 processes do not affect the other, as with
811 .SS C library/kernel differences
814 system call corresponds more closely to
816 in that execution in the child continues from the point of the
824 wrapper function are omitted.
825 Furthermore, the argument order changes.
826 In addition, there are variations across architectures.
828 The raw system call interface on x86-64 and some other architectures
829 (including sh, tile, and alpha) is roughly:
833 .BI "long clone(unsigned long " flags ", void *" child_stack ,
834 .BI " int *" ptid ", int *" ctid ,
835 .BI " unsigned long " newtls );
839 On x86-32, and several other common architectures
840 (including score, ARM, ARM 64, PA-RISC, arc, Power PC, xtensa,
842 .\" CONFIG_CLONE_BACKWARDS
843 the order of the last two arguments is reversed:
847 .BI "long clone(unsigned long " flags ", void *" child_stack ,
848 .BI " int *" ptid ", unsigned long " newtls ,
853 On the cris and s390 architectures,
854 .\" CONFIG_CLONE_BACKWARDS2
855 the order of the first two arguments is reversed:
859 .BI "long clone(void *" child_stack ", unsigned long " flags ,
860 .BI " int *" ptid ", int *" ctid ,
861 .BI " unsigned long " newtls );
865 On the microblaze architecture,
866 .\" CONFIG_CLONE_BACKWARDS3
867 an additional argument is supplied:
871 .BI "long clone(unsigned long " flags ", void *" child_stack ,
872 .BI " int " stack_size , "\fR /* Size of stack */"
873 .BI " int *" ptid ", int *" ctid ,
874 .BI " unsigned long " newtls );
878 Another difference for the raw system call is that the
880 argument may be zero, in which case copy-on-write semantics ensure that the
881 child gets separate copies of stack pages when either process modifies
883 In this case, for correct operation, the
885 option should not be specified.
887 .SS blackfin, m68k, and sparc
888 .\" Mike Frysinger noted in a 2013 mail:
889 .\" these arches don't define __ARCH_WANT_SYS_CLONE:
890 .\" blackfin ia64 m68k sparc
891 The argument-passing conventions on
892 blackfin, m68k, and sparc are different from the descriptions above.
893 For details, see the kernel (and glibc) source.
895 On ia64, a different interface is used:
898 .BI "int __clone2(int (*" "fn" ")(void *), "
899 .BI " void *" child_stack_base ", size_t " stack_size ,
900 .BI " int " flags ", void *" "arg" ", ... "
901 .BI " /* pid_t *" ptid ", struct user_desc *" tls \
902 ", pid_t *" ctid " */ );"
905 The prototype shown above is for the glibc wrapper function;
906 the raw system call interface has no
910 argument, and changes the order of the arguments so that
912 is the first argument, and
914 is the last argument.
917 operates in the same way as
921 points to the lowest address of the child's stack area,
924 specifies the size of the stack pointed to by
925 .IR child_stack_base .
926 .SS Linux 2.4 and earlier
927 In Linux 2.4 and earlier,
929 does not take arguments
935 .\" gettid(2) returns current->pid;
936 .\" getpid(2) returns current->tgid;
937 On success, the thread ID of the child process is returned
938 in the caller's thread of execution.
939 On failure, \-1 is returned
940 in the caller's context, no child process will be created, and
942 will be set appropriately.
946 Too many processes are already running; see
954 (Since Linux 2.6.0-test6.)
961 (Since Linux 2.5.35.)
965 .\" .B CLONE_DETACHED
969 .\" (Since Linux 2.6.0-test6.)
972 .\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71
980 .BR EINVAL " (since Linux 3.9)"
1001 and one (or both) of
1009 Returned by the glibc
1011 wrapper function when
1015 is specified as NULL.
1021 but the kernel was not configured with the
1031 but the kernel was not configured with the
1039 but the kernel was not configured with the
1047 but the kernel was not configured with the
1053 is not aligned to a suitable boundary for this architecture.
1054 For example, on aarch64,
1056 must be a multiple of 16.
1059 Cannot allocate sufficient memory to allocate a task structure for the
1060 child, or to copy those parts of the caller's context that need to be
1070 was specified by an unprivileged process (process without \fBCAP_SYS_ADMIN\fP).
1074 was specified by a process other than process 0.
1080 but either the effective user ID or the effective group ID of the caller
1081 does not have a mapping in the parent namespace (see
1082 .BR user_namespaces (7)).
1084 .BR EPERM " (since Linux 3.9)"
1085 .\" commit 3151527ee007b73a0ebd296010f1c0454a919c7d
1089 and the caller is in a chroot environment
1090 .\" FIXME What is the rationale for this restriction?
1091 (i.e., the caller's root directory does not match the root directory
1092 of the mount namespace in which it resides).
1094 .BR ERESTARTNOINTR " (since Linux 2.6.17)"
1095 .\" commit 4a2c7a7837da1b91468e50426066d988050e4d56
1096 System call was interrupted by a signal and will be restarted.
1097 (This can be seen only during a trace.)
1099 .BR EUSERS " (since Linux 3.11)"
1103 and the call would cause the limit on the number of
1104 nested user namespaces to be exceeded.
1106 .BR user_namespaces (7).
1108 There is no entry for
1113 as described in this manual page.
1116 is Linux-specific and should not be used in programs
1117 intended to be portable.
1121 system call can be used to test whether two processes share various
1122 resources such as a file descriptor table,
1123 System V semaphore undo operations, or a virtual address space.
1125 In the Linux 2.4.x series,
1127 generally does not make the parent of the new thread the same
1128 as the parent of the calling process.
1129 However, for kernel versions 2.4.7 to 2.4.18 the
1133 flag (as in Linux 2.6.0 and later).
1135 For a while there was
1137 (introduced in 2.5.32):
1138 parent wants no child-exit signal.
1139 In Linux 2.6.2, the need to give this flag together with
1142 This flag is still defined, but has no effect.
1146 should not be called through vsyscall, but directly through
1149 Versions of the GNU C library that include the NPTL threading library
1150 contain a wrapper function for
1152 that performs caching of PIDs.
1153 This caching relies on support in the glibc wrapper for
1155 but as currently implemented,
1156 the cache may not be up to date in some circumstances.
1158 if a signal is delivered to the child immediately after the
1160 call, then a call to
1162 in a handler for the signal may return the PID
1163 of the calling process ("the parent"),
1164 if the clone wrapper has not yet had a chance to update the PID
1166 (This discussion ignores the case where the child was created using
1171 return the same value in the child and in the process that called
1173 since the caller and the child are in the same thread group.
1174 The stale-cache problem also does not occur if the
1178 To get the truth, it may be necessary to use code such as the following:
1181 #include <syscall.h>
1185 mypid = syscall(SYS_getpid);
1187 .\" See also the following bug reports
1188 .\" https://bugzilla.redhat.com/show_bug.cgi?id=417521
1189 .\" http://sourceware.org/bugzilla/show_bug.cgi?id=6910
1191 The following program demonstrates the use of
1193 to create a child process that executes in a separate UTS namespace.
1194 The child changes the hostname in its UTS namespace.
1195 Both parent and child then display the system hostname,
1196 making it possible to see that the hostname
1197 differs in the UTS namespaces of the parent and child.
1198 For an example of the use of this program, see
1203 #include <sys/wait.h>
1204 #include <sys/utsname.h>
1211 #define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \\
1214 static int /* Start function for cloned child */
1215 childFunc(void *arg)
1219 /* Change hostname in UTS namespace of child */
1221 if (sethostname(arg, strlen(arg)) == \-1)
1222 errExit("sethostname");
1224 /* Retrieve and display hostname */
1226 if (uname(&uts) == \-1)
1228 printf("uts.nodename in child: %s\\n", uts.nodename);
1230 /* Keep the namespace open for a while, by sleeping.
1231 This allows some experimentation\-\-for example, another
1232 process might join the namespace. */
1236 return 0; /* Child terminates now */
1239 #define STACK_SIZE (1024 * 1024) /* Stack size for cloned child */
1242 main(int argc, char *argv[])
1244 char *stack; /* Start of stack buffer */
1245 char *stackTop; /* End of stack buffer */
1250 fprintf(stderr, "Usage: %s <child\-hostname>\\n", argv[0]);
1254 /* Allocate stack for child */
1256 stack = malloc(STACK_SIZE);
1259 stackTop = stack + STACK_SIZE; /* Assume stack grows downward */
1261 /* Create child that has its own UTS namespace;
1262 child commences execution in childFunc() */
1264 pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]);
1267 printf("clone() returned %ld\\n", (long) pid);
1269 /* Parent falls through to here */
1271 sleep(1); /* Give child time to change its hostname */
1273 /* Display hostname in parent\(aqs UTS namespace. This will be
1274 different from hostname in child\(aqs UTS namespace. */
1276 if (uname(&uts) == \-1)
1278 printf("uts.nodename in parent: %s\\n", uts.nodename);
1280 if (waitpid(pid, NULL, 0) == \-1) /* Wait for child */
1282 printf("child has terminated\\n");
1293 .BR set_thread_area (2),
1294 .BR set_tid_address (2),
1299 .BR capabilities (7),