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 2015-03-29 "Linux" "Linux Programmer's Manual"
44 clone, __clone2 \- create a child process
47 /* Prototype for the glibc wrapper function */
51 .BI "int clone(int (*" "fn" ")(void *), void *" child_stack ,
52 .BI " int " flags ", void *" "arg" ", ... "
53 .BI " /* pid_t *" ptid ", struct user_desc *" tls \
54 ", pid_t *" ctid " */ );"
56 /* Prototype for the raw system call */
58 .BI "long clone(unsigned long " flags ", void *" child_stack ,
59 .BI " void *" ptid ", void *" ctid ,
60 .BI " struct pt_regs *" regs );
64 Feature Test Macro Requirements for glibc wrapper function (see
65 .BR feature_test_macros (7)):
76 .\" See http://sources.redhat.com/bugzilla/show_bug.cgi?id=4749
78 _BSD_SOURCE || _SVID_SOURCE
79 /* _GNU_SOURCE also suffices */
85 creates a new process, in a manner similar to
88 This page describes both the glibc
90 wrapper function and the underlying system call on which it is based.
91 The main text describes the wrapper function;
92 the differences for the raw system call
93 are described toward the end of this page.
98 allows the child process to share parts of its execution context with
99 the calling process, such as the memory space, the table of file
100 descriptors, and the table of signal handlers.
101 (Note that on this manual
102 page, "calling process" normally corresponds to "parent process".
103 But see the description of
109 is to implement threads: multiple threads of control in a program that
110 run concurrently in a shared memory space.
112 When the child process is created with
114 it executes the function
118 where execution continues in the child from the point
124 argument is a pointer to a function that is called by the child
125 process at the beginning of its execution.
128 argument is passed to the
134 function application returns, the child process terminates.
135 The integer returned by
137 is the exit code for the child process.
138 The child process may also terminate explicitly by calling
140 or after receiving a fatal signal.
144 argument specifies the location of the stack used by the child process.
145 Since the child and calling process may share memory,
146 it is not possible for the child process to execute in the
147 same stack as the calling process.
148 The calling process must therefore
149 set up memory space for the child stack and pass a pointer to this
152 Stacks grow downward on all processors that run Linux
153 (except the HP PA processors), so
155 usually points to the topmost address of the memory space set up for
160 contains the number of the
161 .I "termination signal"
162 sent to the parent when the child dies.
163 If this signal is specified as anything other than
165 then the parent process must specify the
169 options when waiting for the child with
171 If no signal is specified, then the parent process is not signaled
172 when the child terminates.
175 may also be bitwise-or'ed with zero or more of the following constants,
176 in order to specify what is shared between the calling process
177 and the child process:
179 .BR CLONE_CHILD_CLEARTID " (since Linux 2.5.49)"
180 Erase the child thread ID at the location
182 in child memory when the child exits, and do a wakeup on the futex
184 The address involved may be changed by the
185 .BR set_tid_address (2)
187 This is used by threading libraries.
189 .BR CLONE_CHILD_SETTID " (since Linux 2.5.49)"
190 Store the child thread ID at the location
192 in the child's memory.
194 .BR CLONE_FILES " (since Linux 2.0)"
197 is set, the calling process and the child process share the same file
199 Any file descriptor created by the calling process or by the child
200 process is also valid in the other process.
201 Similarly, if one of the processes closes a file descriptor,
202 or changes its associated flags (using the
205 operation), the other process is also affected.
206 If a process sharing a file descriptor table calls
208 its file descriptor table is duplicated (unshared).
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 filesystem
229 This includes the root of the filesystem, 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 filesystem
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 Only a privileged process
312 .RB ( CAP_SYS_ADMIN )
315 This flag can't be specified in conjunction with
318 For further information on IPC namespaces, see
321 .BR CLONE_NEWNET " (since Linux 2.6.24)"
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).
353 For further information on network namespaces, see
356 Only a privileged process
357 .RB ( CAP_SYS_ADMIN )
361 .BR CLONE_NEWNS " (since Linux 2.4.19)"
364 is set, the cloned child is started in a new mount namespace,
365 initialized with a copy of the namespace of the parent.
368 is not set, the child lives in the same mount
369 namespace as the parent.
371 For further information on mount namespaces, see
374 Only a privileged process
375 .RB ( CAP_SYS_ADMIN )
378 It is not permitted to specify both
382 .\" See https://lwn.net/Articles/543273/
387 .BR CLONE_NEWPID " (since Linux 2.6.24)"
388 .\" This explanation draws a lot of details from
389 .\" http://lwn.net/Articles/259217/
390 .\" Authors: Pavel Emelyanov <xemul@openvz.org>
391 .\" and Kir Kolyshkin <kir@openvz.org>
393 .\" The primary kernel commit is 30e49c263e36341b60b735cbef5ca37912549264
394 .\" Author: Pavel Emelyanov <xemul@openvz.org>
397 is set, then create the process in a new PID namespace.
398 If this flag is not set, then (as with
400 the process is created in the same PID namespace as
402 This flag is intended for the implementation of containers.
404 For further information on PID namespaces, see
407 .BR pid_namespaces (7)
409 Only a privileged process
410 .RB ( CAP_SYS_ADMIN )
413 This flag can't be specified in conjunction with
419 (This flag first became meaningful for
424 semantics were merged in Linux 3.5,
425 and the final pieces to make the user namespaces completely usable were
426 merged in Linux 3.8.)
430 is set, then create the process in a new user namespace.
431 If this flag is not set, then (as with
433 the process is created in the same user namespace as the calling process.
435 For further information on user namespaces, see
438 .BR user_namespaces (7)
440 Before Linux 3.8, use of
442 required that the caller have three capabilities:
447 .\" Before Linux 2.6.29, it appears that only CAP_SYS_ADMIN was needed
448 Starting with Linux 3.8,
449 no privileges are needed to create a user namespace.
451 This flag can't be specified in conjunction with
455 For security reasons,
456 .\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71
457 .\" https://lwn.net/Articles/543273/
458 .\" The fix actually went into 3.9 and into 3.8.3. However, user namespaces
459 .\" were, for practical purposes, unusable in earlier 3.8.x because of the
460 .\" various filesystems that didn't support userns.
462 cannot be specified in conjunction with
465 For further information on user namespaces, see
466 .BR user_namespaces (7).
468 .BR CLONE_NEWUTS " (since Linux 2.6.19)"
471 is set, then create the process in a new UTS namespace,
472 whose identifiers are initialized by duplicating the identifiers
473 from the UTS namespace of the calling process.
474 If this flag is not set, then (as with
476 the process is created in the same UTS namespace as
478 This flag is intended for the implementation of containers.
480 A UTS namespace is the set of identifiers returned by
482 among these, the domain name and the hostname can be modified by
483 .BR setdomainname (2)
487 Changes made to the identifiers in a UTS namespace
488 are visible to all other processes in the same namespace,
489 but are not visible to processes in other UTS namespaces.
491 Only a privileged process
492 .RB ( CAP_SYS_ADMIN )
496 For further information on UTS namespaces, see
499 .BR CLONE_PARENT " (since Linux 2.3.12)"
502 is set, then the parent of the new child (as returned by
504 will be the same as that of the calling process.
508 is not set, then (as with
510 the child's parent is the calling process.
512 Note that it is the parent process, as returned by
514 which is signaled when the child terminates, so that
517 is set, then the parent of the calling process, rather than the
518 calling process itself, will be signaled.
520 .BR CLONE_PARENT_SETTID " (since Linux 2.5.49)"
521 Store the child thread ID at the location
523 in the parent's memory.
524 (In Linux 2.5.32-2.5.48 there was a flag
528 .BR CLONE_PID " (obsolete)"
531 is set, the child process is created with the same process ID as
533 This is good for hacking the system, but otherwise
535 Since 2.3.21 this flag can be
536 specified only by the system boot process (PID 0).
537 It disappeared in Linux 2.5.16.
538 Since then, the kernel silently ignores it without error.
540 .BR CLONE_PTRACE " (since Linux 2.2)"
543 is specified, and the calling process is being traced,
544 then trace the child also (see
547 .BR CLONE_SETTLS " (since Linux 2.5.32)"
550 argument is the new TLS (Thread Local Storage) descriptor.
552 .BR set_thread_area (2).)
554 .BR CLONE_SIGHAND " (since Linux 2.0)"
557 is set, the calling process and the child process share the same table of
559 If the calling process or child process calls
561 to change the behavior associated with a signal, the behavior is
562 changed in the other process as well.
563 However, the calling process and child
564 processes still have distinct signal masks and sets of pending
566 So, one of them may block or unblock some signals using
568 without affecting the other process.
572 is not set, the child process inherits a copy of the signal handlers
573 of the calling process at the time
578 performed later by one of the processes have no effect on the other
581 Since Linux 2.6.0-test6,
589 .BR CLONE_STOPPED " (since Linux 2.6.0-test2)"
592 is set, then the child is initially stopped (as though it was sent a
594 signal), and must be resumed by sending it a
600 from Linux 2.6.25 onward,
603 altogether in Linux 2.6.38.
604 Since then, the kernel silently ignores it without error.
605 .\" glibc 2.8 removed this defn from bits/sched.h
607 .BR CLONE_SYSVSEM " (since Linux 2.5.10)"
610 is set, then the child and the calling process share
611 a single list of System V semaphore adjustment
615 In this case, the shared list accumulates
617 values across all processes sharing the list,
618 and semaphore adjustments are performed only when the last process
619 that is sharing the list terminates (or ceases sharing the list using
621 If this flag is not set, then the child has a separate
623 list that is initially empty.
625 .BR CLONE_THREAD " (since Linux 2.4.0-test8)"
628 is set, the child is placed in the same thread group as the calling process.
629 To make the remainder of the discussion of
631 more readable, the term "thread" is used to refer to the
632 processes within a thread group.
634 Thread groups were a feature added in Linux 2.4 to support the
635 POSIX threads notion of a set of threads that share a single PID.
636 Internally, this shared PID is the so-called
637 thread group identifier (TGID) for the thread group.
638 Since Linux 2.4, calls to
640 return the TGID of the caller.
642 The threads within a group can be distinguished by their (system-wide)
643 unique thread IDs (TID).
644 A new thread's TID is available as the function result
645 returned to the caller of
647 and a thread can obtain
651 When a call is made to
655 then the resulting thread is placed in a new thread group
656 whose TGID is the same as the thread's TID.
659 of the new thread group.
661 A new thread created with
663 has the same parent process as the caller of
669 return the same value for all of the threads in a thread group.
672 thread terminates, the thread that created it using
676 (or other termination) signal;
677 nor can the status of such a thread be obtained
680 (The thread is said to be
683 After all of the threads in a thread group terminate
684 the parent process of the thread group is sent a
686 (or other termination) signal.
688 If any of the threads in a thread group performs an
690 then all threads other than the thread group leader are terminated,
691 and the new program is executed in the thread group leader.
693 If one of the threads in a thread group creates a child using
695 then any thread in the group can
706 (and note that, since Linux 2.6.0-test6,
712 Signals may be sent to a thread group as a whole (i.e., a TGID) using
714 or to a specific thread (i.e., TID) using
717 Signal dispositions and actions are process-wide:
718 if an unhandled signal is delivered to a thread, then
719 it will affect (terminate, stop, continue, be ignored in)
720 all members of the thread group.
722 Each thread has its own signal mask, as set by
724 but signals can be pending either: for the whole process
725 (i.e., deliverable to any member of the thread group),
728 or for an individual thread, when sent with
732 returns a signal set that is the union of the signals pending for the
733 whole process and the signals that are pending for the calling thread.
737 is used to send a signal to a thread group,
738 and the thread group has installed a handler for the signal, then
739 the handler will be invoked in exactly one, arbitrarily selected
740 member of the thread group that has not blocked the signal.
741 If multiple threads in a group are waiting to accept the same signal using
743 the kernel will arbitrarily select one of these threads
744 to receive a signal sent using
747 .BR CLONE_UNTRACED " (since Linux 2.5.46)"
750 is specified, then a tracing process cannot force
752 on this child process.
754 .BR CLONE_VFORK " (since Linux 2.2)"
757 is set, the execution of the calling process is suspended
758 until the child releases its virtual memory
759 resources via a call to
768 is not set, then both the calling process and the child are schedulable
769 after the call, and an application should not rely on execution occurring
770 in any particular order.
772 .BR CLONE_VM " (since Linux 2.0)"
775 is set, the calling process and the child process run in the same memory
777 In particular, memory writes performed by the calling process
778 or by the child process are also visible in the other process.
779 Moreover, any memory mapping or unmapping performed with
783 by the child or calling process also affects the other process.
787 is not set, the child process runs in a separate copy of the memory
788 space of the calling process at the time of
790 Memory writes or file mappings/unmappings performed by one of the
791 processes do not affect the other, as with
793 .SS C library/kernel differences
796 system call corresponds more closely to
798 in that execution in the child continues from the point of the
806 wrapper function are omitted.
807 Furthermore, the argument order changes.
808 The raw system call interface on x86 and many other architectures is roughly:
812 .BI "long clone(unsigned long " flags ", void *" child_stack ,
813 .BI " void *" ptid ", void *" ctid ,
814 .BI " struct pt_regs *" regs );
818 Another difference for the raw system call is that the
820 argument may be zero, in which case copy-on-write semantics ensure that the
821 child gets separate copies of stack pages when either process modifies
823 In this case, for correct operation, the
825 option should not be specified.
827 For some architectures, the order of the arguments for the system call
828 differs from that shown above.
829 On the score, microblaze, ARM, ARM 64, PA-RISC, arc, Power PC, xtensa,
830 and MIPS architectures,
831 the order of the fourth and fifth arguments is reversed.
832 On the cris and s390 architectures,
833 the order of the first and second arguments is reversed.
834 .SS blackfin, m68k, and sparc
835 The argument-passing conventions on
836 blackfin, m68k, and sparc are different from the descriptions above.
837 For details, see the kernel (and glibc) source.
839 On ia64, a different interface is used:
842 .BI "int __clone2(int (*" "fn" ")(void *), "
843 .BI " void *" child_stack_base ", size_t " stack_size ,
844 .BI " int " flags ", void *" "arg" ", ... "
845 .BI " /* pid_t *" ptid ", struct user_desc *" tls \
846 ", pid_t *" ctid " */ );"
849 The prototype shown above is for the glibc wrapper function;
850 the raw system call interface has no
854 argument, and changes the order of the arguments so that
856 is the first argument, and
858 is the last argument.
861 operates in the same way as
865 points to the lowest address of the child's stack area,
868 specifies the size of the stack pointed to by
869 .IR child_stack_base .
870 .SS Linux 2.4 and earlier
871 In Linux 2.4 and earlier,
873 does not take arguments
879 .\" gettid(2) returns current->pid;
880 .\" getpid(2) returns current->tgid;
881 On success, the thread ID of the child process is returned
882 in the caller's thread of execution.
883 On failure, \-1 is returned
884 in the caller's context, no child process will be created, and
886 will be set appropriately.
890 Too many processes are already running; see
898 (Since Linux 2.6.0-test6.)
905 (Since Linux 2.5.35.)
909 .\" .B CLONE_DETACHED
913 .\" (Since Linux 2.6.0-test6.)
916 .\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71
924 .BR EINVAL " (since Linux 3.9)"
955 when a zero value is specified for
962 but the kernel was not configured with the
972 but the kernel was not configured with the
980 but the kernel was not configured with the
988 but the kernel was not configured with the
993 Cannot allocate sufficient memory to allocate a task structure for the
994 child, or to copy those parts of the caller's context that need to be
1004 was specified by an unprivileged process (process without \fBCAP_SYS_ADMIN\fP).
1008 was specified by a process other than process 0.
1014 but either the effective user ID or the effective group ID of the caller
1015 does not have a mapping in the parent namespace (see
1016 .BR user_namespaces (7)).
1018 .BR EPERM " (since Linux 3.9)"
1019 .\" commit 3151527ee007b73a0ebd296010f1c0454a919c7d
1023 and the caller is in a chroot environment
1024 .\" FIXME What is the rationale for this restriction?
1025 (i.e., the caller's root directory does not match the root directory
1026 of the mount namespace in which it resides).
1028 .BR EUSERS " (since Linux 3.11)"
1032 and the call would cause the limit on the number of
1033 nested user namespaces to be exceeded.
1035 .BR user_namespaces (7).
1037 There is no entry for
1042 as described in this manual page.
1045 is Linux-specific and should not be used in programs
1046 intended to be portable.
1048 In the kernel 2.4.x series,
1050 generally does not make the parent of the new thread the same
1051 as the parent of the calling process.
1052 However, for kernel versions 2.4.7 to 2.4.18 the
1056 flag (as in kernel 2.6).
1058 For a while there was
1060 (introduced in 2.5.32):
1061 parent wants no child-exit signal.
1062 In 2.6.2 the need to give this
1066 This flag is still defined, but has no effect.
1070 should not be called through vsyscall, but directly through
1073 Versions of the GNU C library that include the NPTL threading library
1074 contain a wrapper function for
1076 that performs caching of PIDs.
1077 This caching relies on support in the glibc wrapper for
1079 but as currently implemented,
1080 the cache may not be up to date in some circumstances.
1082 if a signal is delivered to the child immediately after the
1084 call, then a call to
1086 in a handler for the signal may return the PID
1087 of the calling process ("the parent"),
1088 if the clone wrapper has not yet had a chance to update the PID
1090 (This discussion ignores the case where the child was created using
1095 return the same value in the child and in the process that called
1097 since the caller and the child are in the same thread group.
1098 The stale-cache problem also does not occur if the
1102 To get the truth, it may be necessary to use code such as the following:
1105 #include <syscall.h>
1109 mypid = syscall(SYS_getpid);
1111 .\" See also the following bug reports
1112 .\" https://bugzilla.redhat.com/show_bug.cgi?id=417521
1113 .\" http://sourceware.org/bugzilla/show_bug.cgi?id=6910
1115 The following program demonstrates the use of
1117 to create a child process that executes in a separate UTS namespace.
1118 The child changes the hostname in its UTS namespace.
1119 Both parent and child then display the system hostname,
1120 making it possible to see that the hostname
1121 differs in the UTS namespaces of the parent and child.
1122 For an example of the use of this program, see
1127 #include <sys/wait.h>
1128 #include <sys/utsname.h>
1135 #define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \\
1138 static int /* Start function for cloned child */
1139 childFunc(void *arg)
1143 /* Change hostname in UTS namespace of child */
1145 if (sethostname(arg, strlen(arg)) == \-1)
1146 errExit("sethostname");
1148 /* Retrieve and display hostname */
1150 if (uname(&uts) == \-1)
1152 printf("uts.nodename in child: %s\\n", uts.nodename);
1154 /* Keep the namespace open for a while, by sleeping.
1155 This allows some experimentation\-\-for example, another
1156 process might join the namespace. */
1160 return 0; /* Child terminates now */
1163 #define STACK_SIZE (1024 * 1024) /* Stack size for cloned child */
1166 main(int argc, char *argv[])
1168 char *stack; /* Start of stack buffer */
1169 char *stackTop; /* End of stack buffer */
1174 fprintf(stderr, "Usage: %s <child\-hostname>\\n", argv[0]);
1178 /* Allocate stack for child */
1180 stack = malloc(STACK_SIZE);
1183 stackTop = stack + STACK_SIZE; /* Assume stack grows downward */
1185 /* Create child that has its own UTS namespace;
1186 child commences execution in childFunc() */
1188 pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]);
1191 printf("clone() returned %ld\\n", (long) pid);
1193 /* Parent falls through to here */
1195 sleep(1); /* Give child time to change its hostname */
1197 /* Display hostname in parent\(aqs UTS namespace. This will be
1198 different from hostname in child\(aqs UTS namespace. */
1200 if (uname(&uts) == \-1)
1202 printf("uts.nodename in parent: %s\\n", uts.nodename);
1204 if (waitpid(pid, NULL, 0) == \-1) /* Wait for child */
1206 printf("child has terminated\\n");
1217 .BR set_thread_area (2),
1218 .BR set_tid_address (2),
1223 .BR capabilities (7),