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-04-16 "Linux" "Linux Programmer's Manual"
47 clone, __clone2 \- create a child process
50 /* Prototype for the glibc wrapper function */
54 .BI "int clone(int (*" "fn" ")(void *), void *" child_stack ,
55 .BI " int " flags ", void *" "arg" ", ... "
56 .BI " /* pid_t *" ptid ", struct user_desc *" tls \
57 ", pid_t *" ctid " */ );"
59 /* Prototype for the raw system call */
61 .BI "long clone(unsigned long " flags ", void *" child_stack ,
62 .BI " void *" ptid ", void *" ctid ,
63 .BI " struct pt_regs *" regs );
67 Feature Test Macro Requirements for glibc wrapper function (see
68 .BR feature_test_macros (7)):
79 .\" FIXME See http://sources.redhat.com/bugzilla/show_bug.cgi?id=4749
81 _BSD_SOURCE || _SVID_SOURCE
82 /* _GNU_SOURCE also suffices */
88 creates a new process, in a manner similar to
91 This page describes both the glibc
93 wrapper function and the underlying system call on which it is based.
94 The main text describes the wrapper function;
95 the differences for the raw system call
96 are described toward the end of this page.
101 allows the child process to share parts of its execution context with
102 the calling process, such as the memory space, the table of file
103 descriptors, and the table of signal handlers.
104 (Note that on this manual
105 page, "calling process" normally corresponds to "parent process".
106 But see the description of
112 is to implement threads: multiple threads of control in a program that
113 run concurrently in a shared memory space.
115 When the child process is created with
117 it executes the function
121 where execution continues in the child from the point
127 argument is a pointer to a function that is called by the child
128 process at the beginning of its execution.
131 argument is passed to the
137 function application returns, the child process terminates.
138 The integer returned by
140 is the exit code for the child process.
141 The child process may also terminate explicitly by calling
143 or after receiving a fatal signal.
147 argument specifies the location of the stack used by the child process.
148 Since the child and calling process may share memory,
149 it is not possible for the child process to execute in the
150 same stack as the calling process.
151 The calling process must therefore
152 set up memory space for the child stack and pass a pointer to this
155 Stacks grow downward on all processors that run Linux
156 (except the HP PA processors), so
158 usually points to the topmost address of the memory space set up for
163 contains the number of the
164 .I "termination signal"
165 sent to the parent when the child dies.
166 If this signal is specified as anything other than
168 then the parent process must specify the
172 options when waiting for the child with
174 If no signal is specified, then the parent process is not signaled
175 when the child terminates.
178 may also be bitwise-or'ed with zero or more of the following constants,
179 in order to specify what is shared between the calling process
180 and the child process:
182 .BR CLONE_CHILD_CLEARTID " (since Linux 2.5.49)"
183 Erase child thread ID at location
185 in child memory when the child exits, and do a wakeup on the futex
187 The address involved may be changed by the
188 .BR set_tid_address (2)
190 This is used by threading libraries.
192 .BR CLONE_CHILD_SETTID " (since Linux 2.5.49)"
193 Store child thread ID at location
197 .BR CLONE_FILES " (since Linux 2.0)"
200 is set, the calling process and the child process share the same file
202 Any file descriptor created by the calling process or by the child
203 process is also valid in the other process.
204 Similarly, if one of the processes closes a file descriptor,
205 or changes its associated flags (using the
208 operation), the other process is also affected.
212 is not set, the child process inherits a copy of all file descriptors
213 opened in the calling process at the time of
215 (The duplicated file descriptors in the child refer to the
216 same open file descriptions (see
218 as the corresponding file descriptors in the calling process.)
219 Subsequent operations that open or close file descriptors,
220 or change file descriptor flags,
221 performed by either the calling
222 process or the child process do not affect the other process.
224 .BR CLONE_FS " (since Linux 2.0)"
227 is set, the caller and the child process share the same file system
229 This includes the root of the file system, the current
230 working directory, and the umask.
236 performed by the calling process or the child process also affects the
241 is not set, the child process works on a copy of the file system
242 information of the calling process at the time of the
249 performed later by one of the processes do not affect the other process.
251 .BR CLONE_IO " (since Linux 2.6.25)"
254 is set, then the new process shares an I/O context with
256 If this flag is not set, then (as with
258 the new process has its own I/O context.
260 .\" The following based on text from Jens Axboe
261 The I/O context is the I/O scope of the disk scheduler (i.e,
262 what the I/O scheduler uses to model scheduling of a process's I/O).
263 If processes share the same I/O context,
264 they are treated as one by the I/O scheduler.
265 As a consequence, they get to share disk time.
266 For some I/O schedulers,
267 .\" the anticipatory and CFQ scheduler
268 if two processes share an I/O context,
269 they will be allowed to interleave their disk access.
270 If several threads are doing I/O on behalf of the same process
272 for instance), they should employ
274 to get better I/O performance.
277 If the kernel is not configured with the
279 option, this flag is a no-op.
281 .BR CLONE_NEWIPC " (since Linux 2.6.19)"
284 is set, then create the process in a new IPC namespace.
285 If this flag is not set, then (as with
287 the process is created in the same IPC namespace as
289 This flag is intended for the implementation of containers.
291 An IPC namespace provides an isolated view of System V IPC objects (see
293 and (since Linux 2.6.30)
294 .\" commit 7eafd7c74c3f2e67c27621b987b28397110d643f
295 .\" https://lwn.net/Articles/312232/
298 .BR mq_overview (7)).
299 The common characteristic of these IPC mechanisms is that IPC
300 objects are identified by mechanisms other than filesystem
303 Objects created in an IPC namespace are visible to all other processes
304 that are members of that namespace,
305 but are not visible to processes in other IPC namespaces.
307 When an IPC namespace is destroyed
308 (i.e., when the last process that is a member of the namespace terminates),
309 all IPC objects in the namespace are automatically destroyed.
311 Use of this flag requires: a kernel configured with the
315 options and that the process be privileged
316 .RB ( CAP_SYS_ADMIN ).
317 This flag can't be specified in conjunction with
320 .BR CLONE_NEWNET " (since Linux 2.6.24)"
321 .\" FIXME Check when the implementation was completed
322 (The implementation of this flag was completed only
323 by about kernel version 2.6.29.)
327 is set, then create the process in a new network namespace.
328 If this flag is not set, then (as with
330 the process is created in the same network namespace as
332 This flag is intended for the implementation of containers.
334 A network namespace provides an isolated view of the networking stack
335 (network device interfaces, IPv4 and IPv6 protocol stacks,
336 IP routing tables, firewall rules, the
340 directory trees, sockets, etc.).
341 A physical network device can live in exactly one
343 A virtual network device ("veth") pair provides a pipe-like abstraction
344 .\" FIXME Add pointer to veth(4) page when it is eventually completed
345 that can be used to create tunnels between network namespaces,
346 and can be used to create a bridge to a physical network device
347 in another namespace.
349 When a network namespace is freed
350 (i.e., when the last process in the namespace terminates),
351 its physical network devices are moved back to the
352 initial network namespace (not to the parent of the process).
354 Use of this flag requires: a kernel configured with the
356 option and that the process be privileged
357 .RB ( CAP_SYS_ADMIN ).
359 .BR CLONE_NEWNS " (since Linux 2.4.19)"
360 Start the child in a new mount namespace.
362 Every process lives in a mount namespace.
365 of a process is the data (the set of mounts) describing the file hierarchy
366 as seen by that process.
373 flag is not set, the child lives in the same mount
374 namespace as the parent.
379 change the mount namespace of the calling process, and hence affect
380 all processes that live in the same namespace, but do not affect
381 processes in a different mount namespace.
387 flag is set, the cloned child is started in a new mount namespace,
388 initialized with a copy of the namespace of the parent.
390 Only a privileged process (one having the \fBCAP_SYS_ADMIN\fP capability)
394 It is not permitted to specify both
402 .BR CLONE_NEWPID " (since Linux 2.6.24)"
403 .\" This explanation draws a lot of details from
404 .\" http://lwn.net/Articles/259217/
405 .\" Authors: Pavel Emelyanov <xemul@openvz.org>
406 .\" and Kir Kolyshkin <kir@openvz.org>
408 .\" The primary kernel commit is 30e49c263e36341b60b735cbef5ca37912549264
409 .\" Author: Pavel Emelyanov <xemul@openvz.org>
412 is set, then create the process in a new PID namespace.
413 If this flag is not set, then (as with
415 the process is created in the same PID namespace as
417 This flag is intended for the implementation of containers.
419 A PID namespace provides an isolated environment for PIDs:
420 PIDs in a new namespace start at 1,
421 somewhat like a standalone system, and calls to
426 will produce processes with PIDs that are unique within the namespace.
428 The first process created in a new namespace
429 (i.e., the process created using the
431 flag) has the PID 1, and is the "init" process for the namespace.
432 Children that are orphaned within the namespace will be reparented
433 to this process rather than
435 Unlike the traditional
437 process, the "init" process of a PID namespace can terminate,
438 and if it does, all of the processes in the namespace are terminated.
440 PID namespaces form a hierarchy.
441 When a new PID namespace is created,
442 the processes in that namespace are visible
443 in the PID namespace of the process that created the new namespace;
444 analogously, if the parent PID namespace is itself
445 the child of another PID namespace,
446 then processes in the child and parent PID namespaces will both be
447 visible in the grandparent PID namespace.
448 Conversely, the processes in the "child" PID namespace do not see
449 the processes in the parent namespace.
450 The existence of a namespace hierarchy means that each process
451 may now have multiple PIDs:
452 one for each namespace in which it is visible;
453 each of these PIDs is unique within the corresponding namespace.
456 always returns the PID associated with the namespace in which
459 After creating the new namespace,
460 it is useful for the child to change its root directory
461 and mount a new procfs instance at
463 so that tools such as
466 .\" mount -t proc proc /proc
471 then it isn't necessary to change the root directory:
472 a new procfs instance can be mounted directly over
475 Use of this flag requires: a kernel configured with the
477 option and that the process be privileged
478 .RB ( CAP_SYS_ADMIN ).
479 This flag can't be specified in conjunction with
482 .BR CLONE_NEWUTS " (since Linux 2.6.19)"
485 is set, then create the process in a new UTS namespace,
486 whose identifiers are initialized by duplicating the identifiers
487 from the UTS namespace of the calling process.
488 If this flag is not set, then (as with
490 the process is created in the same UTS namespace as
492 This flag is intended for the implementation of containers.
494 A UTS namespace is the set of identifiers returned by
496 among these, the domain name and the host name can be modified by
497 .BR setdomainname (2)
502 Changes made to the identifiers in a UTS namespace
503 are visible to all other processes in the same namespace,
504 but are not visible to processes in other UTS namespaces.
506 Use of this flag requires: a kernel configured with the
508 option and that the process be privileged
509 .RB ( CAP_SYS_ADMIN ).
511 .BR CLONE_PARENT " (since Linux 2.3.12)"
514 is set, then the parent of the new child (as returned by
516 will be the same as that of the calling process.
520 is not set, then (as with
522 the child's parent is the calling process.
524 Note that it is the parent process, as returned by
526 which is signaled when the child terminates, so that
529 is set, then the parent of the calling process, rather than the
530 calling process itself, will be signaled.
532 .BR CLONE_PARENT_SETTID " (since Linux 2.5.49)"
533 Store child thread ID at location
535 in parent and child memory.
536 (In Linux 2.5.32-2.5.48 there was a flag
540 .BR CLONE_PID " (obsolete)"
543 is set, the child process is created with the same process ID as
545 This is good for hacking the system, but otherwise
547 Since 2.3.21 this flag can be
548 specified only by the system boot process (PID 0).
549 It disappeared in Linux 2.5.16.
551 .BR CLONE_PTRACE " (since Linux 2.2)"
554 is specified, and the calling process is being traced,
555 then trace the child also (see
558 .BR CLONE_SETTLS " (since Linux 2.5.32)"
561 argument is the new TLS (Thread Local Storage) descriptor.
563 .BR set_thread_area (2).)
565 .BR CLONE_SIGHAND " (since Linux 2.0)"
568 is set, the calling process and the child process share the same table of
570 If the calling process or child process calls
572 to change the behavior associated with a signal, the behavior is
573 changed in the other process as well.
574 However, the calling process and child
575 processes still have distinct signal masks and sets of pending
577 So, one of them may block or unblock some signals using
579 without affecting the other process.
583 is not set, the child process inherits a copy of the signal handlers
584 of the calling process at the time
589 performed later by one of the processes have no effect on the other
592 Since Linux 2.6.0-test6,
600 .BR CLONE_STOPPED " (since Linux 2.6.0-test2)"
603 is set, then the child is initially stopped (as though it was sent a
605 signal), and must be resumed by sending it a
611 from Linux 2.6.25 onward,
614 altogether in Linux 2.6.38.
615 .\" glibc 2.8 removed this defn from bits/sched.h
617 .BR CLONE_SYSVSEM " (since Linux 2.5.10)"
620 is set, then the child and the calling process share
621 a single list of System V semaphore undo values (see
623 If this flag is not set, then the child has a separate undo list,
624 which is initially empty.
626 .BR CLONE_THREAD " (since Linux 2.4.0-test8)"
629 is set, the child is placed in the same thread group as the calling process.
630 To make the remainder of the discussion of
632 more readable, the term "thread" is used to refer to the
633 processes within a thread group.
635 Thread groups were a feature added in Linux 2.4 to support the
636 POSIX threads notion of a set of threads that share a single PID.
637 Internally, this shared PID is the so-called
638 thread group identifier (TGID) for the thread group.
639 Since Linux 2.4, calls to
641 return the TGID of the caller.
643 The threads within a group can be distinguished by their (system-wide)
644 unique thread IDs (TID).
645 A new thread's TID is available as the function result
646 returned to the caller of
648 and a thread can obtain
652 When a call is made to
656 then the resulting thread is placed in a new thread group
657 whose TGID is the same as the thread's TID.
660 of the new thread group.
662 A new thread created with
664 has the same parent process as the caller of
670 return the same value for all of the threads in a thread group.
673 thread terminates, the thread that created it using
677 (or other termination) signal;
678 nor can the status of such a thread be obtained
681 (The thread is said to be
684 After all of the threads in a thread group terminate
685 the parent process of the thread group is sent a
687 (or other termination) signal.
689 If any of the threads in a thread group performs an
691 then all threads other than the thread group leader are terminated,
692 and the new program is executed in the thread group leader.
694 If one of the threads in a thread group creates a child using
696 then any thread in the group can
708 Signals may be sent to a thread group as a whole (i.e., a TGID) using
710 or to a specific thread (i.e., TID) using
713 Signal dispositions and actions are process-wide:
714 if an unhandled signal is delivered to a thread, then
715 it will affect (terminate, stop, continue, be ignored in)
716 all members of the thread group.
718 Each thread has its own signal mask, as set by
720 but signals can be pending either: for the whole process
721 (i.e., deliverable to any member of the thread group),
724 or for an individual thread, when sent with
728 returns a signal set that is the union of the signals pending for the
729 whole process and the signals that are pending for the calling thread.
733 is used to send a signal to a thread group,
734 and the thread group has installed a handler for the signal, then
735 the handler will be invoked in exactly one, arbitrarily selected
736 member of the thread group that has not blocked the signal.
737 If multiple threads in a group are waiting to accept the same signal using
739 the kernel will arbitrarily select one of these threads
740 to receive a signal sent using
743 .BR CLONE_UNTRACED " (since Linux 2.5.46)"
746 is specified, then a tracing process cannot force
748 on this child process.
750 .BR CLONE_VFORK " (since Linux 2.2)"
753 is set, the execution of the calling process is suspended
754 until the child releases its virtual memory
755 resources via a call to
764 is not set then both the calling process and the child are schedulable
765 after the call, and an application should not rely on execution occurring
766 in any particular order.
768 .BR CLONE_VM " (since Linux 2.0)"
771 is set, the calling process and the child process run in the same memory
773 In particular, memory writes performed by the calling process
774 or by the child process are also visible in the other process.
775 Moreover, any memory mapping or unmapping performed with
779 by the child or calling process also affects the other process.
783 is not set, the child process runs in a separate copy of the memory
784 space of the calling process at the time of
786 Memory writes or file mappings/unmappings performed by one of the
787 processes do not affect the other, as with
789 .SS The raw system call interface
792 system call corresponds more closely to
794 in that execution in the child continues from the point of the
802 wrapper function are omitted.
803 Furthermore, the argument order changes.
804 The raw system call interface on x86 and many other architectures is roughly:
808 .BI "long clone(unsigned long " flags ", void *" child_stack ,
809 .BI " void *" ptid ", void *" ctid ,
810 .BI " struct pt_regs *" regs );
814 Another difference for the raw system call is that the
816 argument may be zero, in which case copy-on-write semantics ensure that the
817 child gets separate copies of stack pages when either process modifies
819 In this case, for correct operation, the
821 option should not be specified.
823 For some architectures, the order of the arguments for the system call
824 differs from that shown above.
825 On the score, microblaze, ARM, ARM 64, PA-RISC, arc, Power PC, xtensa,
826 and MIPS architectures,
827 the order of the fourth and fifth arguments is reversed.
828 On the cris and s390 architectures,
829 the order of the first and second arguments is reversed.
830 .SS Linux 2.4 and earlier
831 In Linux 2.4 and earlier,
833 does not take arguments
839 .\" gettid(2) returns current->pid;
840 .\" getpid(2) returns current->tgid;
841 On success, the thread ID of the child process is returned
842 in the caller's thread of execution.
843 On failure, \-1 is returned
844 in the caller's context, no child process will be created, and
846 will be set appropriately.
850 Too many processes are already running.
857 (Since Linux 2.6.0-test6.)
864 (Since Linux 2.5.35.)
868 .\" .B CLONE_DETACHED
872 .\" (Since Linux 2.6.0-test6.)
901 when a zero value is specified for
908 but the kernel was not configured with the
918 but the kernel was not configured with the
926 but the kernel was not configured with the
934 but the kernel was not configured with the
939 Cannot allocate sufficient memory to allocate a task structure for the
940 child, or to copy those parts of the caller's context that need to be
950 was specified by an unprivileged process (process without \fBCAP_SYS_ADMIN\fP).
954 was specified by a process other than process 0.
956 There is no entry for
961 as described in this manual page.
964 is Linux-specific and should not be used in programs
965 intended to be portable.
967 In the kernel 2.4.x series,
969 generally does not make the parent of the new thread the same
970 as the parent of the calling process.
971 However, for kernel versions 2.4.7 to 2.4.18 the
975 flag (as in kernel 2.6).
977 For a while there was
979 (introduced in 2.5.32):
980 parent wants no child-exit signal.
981 In 2.6.2 the need to give this
985 This flag is still defined, but has no effect.
989 should not be called through vsyscall, but directly through
992 On ia64, a different system call is used:
995 .BI "int __clone2(int (*" "fn" ")(void *), "
996 .BI " void *" child_stack_base ", size_t " stack_size ,
997 .BI " int " flags ", void *" "arg" ", ... "
998 .BI " /* pid_t *" ptid ", struct user_desc *" tls \
999 ", pid_t *" ctid " */ );"
1004 system call operates in the same way as
1008 points to the lowest address of the child's stack area,
1011 specifies the size of the stack pointed to by
1012 .IR child_stack_base .
1014 Versions of the GNU C library that include the NPTL threading library
1015 contain a wrapper function for
1017 that performs caching of PIDs.
1018 This caching relies on support in the glibc wrapper for
1020 but as currently implemented,
1021 the cache may not be up to date in some circumstances.
1023 if a signal is delivered to the child immediately after the
1025 call, then a call to
1027 in a handler for the signal may return the PID
1028 of the calling process ("the parent"),
1029 if the clone wrapper has not yet had a chance to update the PID
1031 (This discussion ignores the case where the child was created using
1036 return the same value in the child and in the process that called
1038 since the caller and the child are in the same thread group.
1039 The stale-cache problem also does not occur if the
1043 To get the truth, it may be necessary to use code such as the following:
1046 #include <syscall.h>
1050 mypid = syscall(SYS_getpid);
1052 .\" See also the following bug reports
1053 .\" https://bugzilla.redhat.com/show_bug.cgi?id=417521
1054 .\" http://sourceware.org/bugzilla/show_bug.cgi?id=6910
1056 .SS Create a child that executes in a separate UTS namespace
1057 The following program demonstrates the use of
1059 to create a child process that executes in a separate UTS namespace.
1060 The child changes the hostname in its UTS namespace.
1061 Both parent and child then display the system hostname,
1062 making it possible to see that the hostname
1063 differs in the UTS namespaces of the parent and child.
1064 For an example of the use of this program, see
1069 #include <sys/wait.h>
1070 #include <sys/utsname.h>
1077 #define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \\
1080 static int /* Start function for cloned child */
1081 childFunc(void *arg)
1085 /* Change hostname in UTS namespace of child */
1087 if (sethostname(arg, strlen(arg)) == \-1)
1088 errExit("sethostname");
1090 /* Retrieve and display hostname */
1092 if (uname(&uts) == \-1)
1094 printf("uts.nodename in child: %s\\n", uts.nodename);
1096 /* Keep the namespace open for a while, by sleeping.
1097 This allows some experimentation\-\-for example, another
1098 process might join the namespace. */
1102 return 0; /* Child terminates now */
1105 #define STACK_SIZE (1024 * 1024) /* Stack size for cloned child */
1108 main(int argc, char *argv[])
1110 char *stack; /* Start of stack buffer */
1111 char *stackTop; /* End of stack buffer */
1116 fprintf(stderr, "Usage: %s <child\-hostname>\\n", argv[0]);
1120 /* Allocate stack for child */
1122 stack = malloc(STACK_SIZE);
1125 stackTop = stack + STACK_SIZE; /* Assume stack grows downward */
1127 /* Create child that has its own UTS namespace;
1128 child commences execution in childFunc() */
1130 pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]);
1133 printf("clone() returned %ld\\n", (long) pid);
1135 /* Parent falls through to here */
1137 sleep(1); /* Give child time to change its hostname */
1139 /* Display hostname in parent\(aqs UTS namespace. This will be
1140 different from hostname in child\(aqs UTS namespace. */
1142 if (uname(&uts) == \-1)
1144 printf("uts.nodename in parent: %s\\n", uts.nodename);
1146 if (waitpid(pid, NULL, 0) == \-1) /* Wait for child */
1148 printf("child has terminated\\n");
1159 .BR set_thread_area (2),
1160 .BR set_tid_address (2),
1165 .BR capabilities (7),