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 2014-08-19 "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 child thread ID at 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 child thread ID at location
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.
209 is not set, the child process inherits a copy of all file descriptors
210 opened in the calling process at the time of
212 (The duplicated file descriptors in the child refer to the
213 same open file descriptions (see
215 as the corresponding file descriptors in the calling process.)
216 Subsequent operations that open or close file descriptors,
217 or change file descriptor flags,
218 performed by either the calling
219 process or the child process do not affect the other process.
221 .BR CLONE_FS " (since Linux 2.0)"
224 is set, the caller and the child process share the same filesystem
226 This includes the root of the filesystem, the current
227 working directory, and the umask.
233 performed by the calling process or the child process also affects the
238 is not set, the child process works on a copy of the filesystem
239 information of the calling process at the time of the
246 performed later by one of the processes do not affect the other process.
248 .BR CLONE_IO " (since Linux 2.6.25)"
251 is set, then the new process shares an I/O context with
253 If this flag is not set, then (as with
255 the new process has its own I/O context.
257 .\" The following based on text from Jens Axboe
258 The I/O context is the I/O scope of the disk scheduler (i.e,
259 what the I/O scheduler uses to model scheduling of a process's I/O).
260 If processes share the same I/O context,
261 they are treated as one by the I/O scheduler.
262 As a consequence, they get to share disk time.
263 For some I/O schedulers,
264 .\" the anticipatory and CFQ scheduler
265 if two processes share an I/O context,
266 they will be allowed to interleave their disk access.
267 If several threads are doing I/O on behalf of the same process
269 for instance), they should employ
271 to get better I/O performance.
274 If the kernel is not configured with the
276 option, this flag is a no-op.
278 .BR CLONE_NEWIPC " (since Linux 2.6.19)"
281 is set, then create the process in a new IPC namespace.
282 If this flag is not set, then (as with
284 the process is created in the same IPC namespace as
286 This flag is intended for the implementation of containers.
288 An IPC namespace provides an isolated view of System\ V IPC objects (see
290 and (since Linux 2.6.30)
291 .\" commit 7eafd7c74c3f2e67c27621b987b28397110d643f
292 .\" https://lwn.net/Articles/312232/
295 .BR mq_overview (7)).
296 The common characteristic of these IPC mechanisms is that IPC
297 objects are identified by mechanisms other than filesystem
300 Objects created in an IPC namespace are visible to all other processes
301 that are members of that namespace,
302 but are not visible to processes in other IPC namespaces.
304 When an IPC namespace is destroyed
305 (i.e., when the last process that is a member of the namespace terminates),
306 all IPC objects in the namespace are automatically destroyed.
308 Use of this flag requires
309 that the process be privileged
310 .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 Use of this flag requires
353 that the process be privileged
354 .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 For further information on mount namespaces, see
370 Only a privileged process (one having the \fBCAP_SYS_ADMIN\fP capability)
374 It is not permitted to specify both
384 (This flag first became meaningful for
389 semantics were merged in Linux 3.5,
390 and the final pieces to make the user namespaces completely usable were
391 merged in Linux 3.8.)
395 is set, then create the process in a new user namespace.
396 If this flag is not set, then (as with
398 the process is created in the same user namespace as the calling process.
400 A user namespace provides an isolated environment for
401 security related identifiers, in particular,
402 user IDs, group IDs, keys (see
406 When a user namespace is created,
407 it starts out without a mapping of user IDs (group IDs)
408 to the parent user namespace.
409 The desired mapping of user IDs (group IDs) to the parent user namespace
410 may be set by writing into
411 .IR /proc/[pid]/uid_map
412 .RI ( /proc/[pid]/gid_map );
416 The first process in a user namespace starts out with a complete set
417 of capabilities with respect to the new user namespace.
419 System calls that return user IDs (group IDs) will return
420 either the user ID (group ID) mapped into the current
421 user namespace if there is a mapping, or the overflow user ID (group ID);
422 the default value for the overflow user ID (group ID) is 65534.
423 See the descriptions of
424 .IR /proc/sys/kernel/overflowuid
426 .IR /proc/sys/kernel/overflowgid
430 Use of this flag requires a kernel configured with the
433 Before Linux 3.8, use of
435 required that the caller have three capabilities:
440 .\" Before Linux 2.6.29, it appears that only CAP_SYS_ADMIN was needed
441 Starting with Linux 3.8,
442 no privileges are needed to create a user namespace,
443 and mount, PID, IPC, network, and UTS namespaces can be created with just the
445 capability in the caller's user namespace.
449 is specified along with other
453 call, the user namespace is guaranteed to be created first,
454 giving the caller privileges over the remaining
455 namespaces created by the call.
456 Thus, it possible for an unprivileged caller to specify this combination
459 Over the years, there have been a lot of features that have been added
460 to the Linux kernel that are only available to privileged users
461 because of their potential to confuse set-user-ID-root applications.
462 In general, it becomes safe to allow the root user in a user namespace to
463 use those features because it is impossible, while in a user namespace,
464 to gain more privilege than the root user of a user namespace has.
467 .BR CLONE_NEWPID " (since Linux 2.6.24)"
468 .\" This explanation draws a lot of details from
469 .\" http://lwn.net/Articles/259217/
470 .\" Authors: Pavel Emelyanov <xemul@openvz.org>
471 .\" and Kir Kolyshkin <kir@openvz.org>
473 .\" The primary kernel commit is 30e49c263e36341b60b735cbef5ca37912549264
474 .\" Author: Pavel Emelyanov <xemul@openvz.org>
477 is set, then create the process in a new PID namespace.
478 If this flag is not set, then (as with
480 the process is created in the same PID namespace as
482 This flag is intended for the implementation of containers.
484 A PID namespace provides an isolated environment for PIDs:
485 PIDs in a new namespace start at 1,
486 somewhat like a standalone system, and calls to
491 will produce processes with PIDs that are unique within the namespace.
493 The first process created in a new namespace
494 (i.e., the process created using the
496 flag) has the PID 1, and is the "init" process for the namespace.
497 Children that are orphaned within the namespace will be reparented
498 to this process rather than
500 Unlike the traditional
502 process, the "init" process of a PID namespace can terminate,
503 and if it does, all of the processes in the namespace are terminated.
505 PID namespaces form a hierarchy.
506 When a new PID namespace is created,
507 the processes in that namespace are visible
508 in the PID namespace of the process that created the new namespace;
509 analogously, if the parent PID namespace is itself
510 the child of another PID namespace,
511 then processes in the child and parent PID namespaces will both be
512 visible in the grandparent PID namespace.
513 Conversely, the processes in the "child" PID namespace do not see
514 the processes in the parent namespace.
515 The existence of a namespace hierarchy means that each process
516 may now have multiple PIDs:
517 one for each namespace in which it is visible;
518 each of these PIDs is unique within the corresponding namespace.
521 always returns the PID associated with the namespace in which
524 After creating the new namespace,
525 it is useful for the child to change its root directory
526 and mount a new procfs instance at
528 so that tools such as
531 .\" mount -t proc proc /proc
536 then it isn't necessary to change the root directory:
537 a new procfs instance can be mounted directly over
540 Use of this flag requires: a kernel configured with the
542 option and that the process be privileged
543 .RB ( CAP_SYS_ADMIN ).
544 This flag can't be specified in conjunction with
547 .BR CLONE_NEWUTS " (since Linux 2.6.19)"
550 is set, then create the process in a new UTS namespace,
551 whose identifiers are initialized by duplicating the identifiers
552 from the UTS namespace of the calling process.
553 If this flag is not set, then (as with
555 the process is created in the same UTS namespace as
557 This flag is intended for the implementation of containers.
559 A UTS namespace is the set of identifiers returned by
561 among these, the domain name and the hostname can be modified by
562 .BR setdomainname (2)
566 Changes made to the identifiers in a UTS namespace
567 are visible to all other processes in the same namespace,
568 but are not visible to processes in other UTS namespaces.
570 Use of this flag requires: a kernel configured with the
572 option and that the process be privileged
573 .RB ( CAP_SYS_ADMIN ).
575 .BR CLONE_PARENT " (since Linux 2.3.12)"
578 is set, then the parent of the new child (as returned by
580 will be the same as that of the calling process.
584 is not set, then (as with
586 the child's parent is the calling process.
588 Note that it is the parent process, as returned by
590 which is signaled when the child terminates, so that
593 is set, then the parent of the calling process, rather than the
594 calling process itself, will be signaled.
596 .BR CLONE_PARENT_SETTID " (since Linux 2.5.49)"
597 Store child thread ID at location
599 in parent and child memory.
600 (In Linux 2.5.32-2.5.48 there was a flag
604 .BR CLONE_PID " (obsolete)"
607 is set, the child process is created with the same process ID as
609 This is good for hacking the system, but otherwise
611 Since 2.3.21 this flag can be
612 specified only by the system boot process (PID 0).
613 It disappeared in Linux 2.5.16.
615 .BR CLONE_PTRACE " (since Linux 2.2)"
618 is specified, and the calling process is being traced,
619 then trace the child also (see
622 .BR CLONE_SETTLS " (since Linux 2.5.32)"
625 argument is the new TLS (Thread Local Storage) descriptor.
627 .BR set_thread_area (2).)
629 .BR CLONE_SIGHAND " (since Linux 2.0)"
632 is set, the calling process and the child process share the same table of
634 If the calling process or child process calls
636 to change the behavior associated with a signal, the behavior is
637 changed in the other process as well.
638 However, the calling process and child
639 processes still have distinct signal masks and sets of pending
641 So, one of them may block or unblock some signals using
643 without affecting the other process.
647 is not set, the child process inherits a copy of the signal handlers
648 of the calling process at the time
653 performed later by one of the processes have no effect on the other
656 Since Linux 2.6.0-test6,
664 .BR CLONE_STOPPED " (since Linux 2.6.0-test2)"
667 is set, then the child is initially stopped (as though it was sent a
669 signal), and must be resumed by sending it a
675 from Linux 2.6.25 onward,
678 altogether in Linux 2.6.38.
679 .\" glibc 2.8 removed this defn from bits/sched.h
681 .BR CLONE_SYSVSEM " (since Linux 2.5.10)"
684 is set, then the child and the calling process share
685 a single list of System\ V semaphore undo values (see
687 If this flag is not set, then the child has a separate undo list,
688 which is initially empty.
690 .BR CLONE_THREAD " (since Linux 2.4.0-test8)"
693 is set, the child is placed in the same thread group as the calling process.
694 To make the remainder of the discussion of
696 more readable, the term "thread" is used to refer to the
697 processes within a thread group.
699 Thread groups were a feature added in Linux 2.4 to support the
700 POSIX threads notion of a set of threads that share a single PID.
701 Internally, this shared PID is the so-called
702 thread group identifier (TGID) for the thread group.
703 Since Linux 2.4, calls to
705 return the TGID of the caller.
707 The threads within a group can be distinguished by their (system-wide)
708 unique thread IDs (TID).
709 A new thread's TID is available as the function result
710 returned to the caller of
712 and a thread can obtain
716 When a call is made to
720 then the resulting thread is placed in a new thread group
721 whose TGID is the same as the thread's TID.
724 of the new thread group.
726 A new thread created with
728 has the same parent process as the caller of
734 return the same value for all of the threads in a thread group.
737 thread terminates, the thread that created it using
741 (or other termination) signal;
742 nor can the status of such a thread be obtained
745 (The thread is said to be
748 After all of the threads in a thread group terminate
749 the parent process of the thread group is sent a
751 (or other termination) signal.
753 If any of the threads in a thread group performs an
755 then all threads other than the thread group leader are terminated,
756 and the new program is executed in the thread group leader.
758 If one of the threads in a thread group creates a child using
760 then any thread in the group can
771 (and note that, since Linux 2.6.0-test6,
777 Signals may be sent to a thread group as a whole (i.e., a TGID) using
779 or to a specific thread (i.e., TID) using
782 Signal dispositions and actions are process-wide:
783 if an unhandled signal is delivered to a thread, then
784 it will affect (terminate, stop, continue, be ignored in)
785 all members of the thread group.
787 Each thread has its own signal mask, as set by
789 but signals can be pending either: for the whole process
790 (i.e., deliverable to any member of the thread group),
793 or for an individual thread, when sent with
797 returns a signal set that is the union of the signals pending for the
798 whole process and the signals that are pending for the calling thread.
802 is used to send a signal to a thread group,
803 and the thread group has installed a handler for the signal, then
804 the handler will be invoked in exactly one, arbitrarily selected
805 member of the thread group that has not blocked the signal.
806 If multiple threads in a group are waiting to accept the same signal using
808 the kernel will arbitrarily select one of these threads
809 to receive a signal sent using
812 .BR CLONE_UNTRACED " (since Linux 2.5.46)"
815 is specified, then a tracing process cannot force
817 on this child process.
819 .BR CLONE_VFORK " (since Linux 2.2)"
822 is set, the execution of the calling process is suspended
823 until the child releases its virtual memory
824 resources via a call to
833 is not set, then both the calling process and the child are schedulable
834 after the call, and an application should not rely on execution occurring
835 in any particular order.
837 .BR CLONE_VM " (since Linux 2.0)"
840 is set, the calling process and the child process run in the same memory
842 In particular, memory writes performed by the calling process
843 or by the child process are also visible in the other process.
844 Moreover, any memory mapping or unmapping performed with
848 by the child or calling process also affects the other process.
852 is not set, the child process runs in a separate copy of the memory
853 space of the calling process at the time of
855 Memory writes or file mappings/unmappings performed by one of the
856 processes do not affect the other, as with
858 .SS C library/kernel ABI differences
861 system call corresponds more closely to
863 in that execution in the child continues from the point of the
871 wrapper function are omitted.
872 Furthermore, the argument order changes.
873 The raw system call interface on x86 and many other architectures is roughly:
877 .BI "long clone(unsigned long " flags ", void *" child_stack ,
878 .BI " void *" ptid ", void *" ctid ,
879 .BI " struct pt_regs *" regs );
883 Another difference for the raw system call is that the
885 argument may be zero, in which case copy-on-write semantics ensure that the
886 child gets separate copies of stack pages when either process modifies
888 In this case, for correct operation, the
890 option should not be specified.
892 For some architectures, the order of the arguments for the system call
893 differs from that shown above.
894 On the score, microblaze, ARM, ARM 64, PA-RISC, arc, Power PC, xtensa,
895 and MIPS architectures,
896 the order of the fourth and fifth arguments is reversed.
897 On the cris and s390 architectures,
898 the order of the first and second arguments is reversed.
899 .SS blackfin, m68k, and sparc
900 The argument-passing conventions on
901 blackfin, m68k, and sparc are different from the descriptions above.
902 For details, see the kernel (and glibc) source.
904 On ia64, a different interface is used:
907 .BI "int __clone2(int (*" "fn" ")(void *), "
908 .BI " void *" child_stack_base ", size_t " stack_size ,
909 .BI " int " flags ", void *" "arg" ", ... "
910 .BI " /* pid_t *" ptid ", struct user_desc *" tls \
911 ", pid_t *" ctid " */ );"
914 The prototype shown above is for the glibc wrapper function;
915 the raw system call interface has no
919 argument, and changes the order of the arguments so that
921 is the first argument, and
923 is the last argument.
926 operates in the same way as
930 points to the lowest address of the child's stack area,
933 specifies the size of the stack pointed to by
934 .IR child_stack_base .
935 .SS Linux 2.4 and earlier
936 In Linux 2.4 and earlier,
938 does not take arguments
944 .\" gettid(2) returns current->pid;
945 .\" getpid(2) returns current->tgid;
946 On success, the thread ID of the child process is returned
947 in the caller's thread of execution.
948 On failure, \-1 is returned
949 in the caller's context, no child process will be created, and
951 will be set appropriately.
955 Too many processes are already running; see
963 (Since Linux 2.6.0-test6.)
970 (Since Linux 2.5.35.)
974 .\" .B CLONE_DETACHED
978 .\" (Since Linux 2.6.0-test6.)
1007 when a zero value is specified for
1014 but the kernel was not configured with the
1024 but the kernel was not configured with the
1032 but the kernel was not configured with the
1040 but the kernel was not configured with the
1045 Cannot allocate sufficient memory to allocate a task structure for the
1046 child, or to copy those parts of the caller's context that need to be
1056 was specified by an unprivileged process (process without \fBCAP_SYS_ADMIN\fP).
1060 was specified by a process other than process 0.
1063 is Linux-specific and should not be used in programs
1064 intended to be portable.
1066 In the kernel 2.4.x series,
1068 generally does not make the parent of the new thread the same
1069 as the parent of the calling process.
1070 However, for kernel versions 2.4.7 to 2.4.18 the
1074 flag (as in kernel 2.6).
1076 For a while there was
1078 (introduced in 2.5.32):
1079 parent wants no child-exit signal.
1080 In 2.6.2 the need to give this
1084 This flag is still defined, but has no effect.
1088 should not be called through vsyscall, but directly through
1091 Versions of the GNU C library that include the NPTL threading library
1092 contain a wrapper function for
1094 that performs caching of PIDs.
1095 This caching relies on support in the glibc wrapper for
1097 but as currently implemented,
1098 the cache may not be up to date in some circumstances.
1100 if a signal is delivered to the child immediately after the
1102 call, then a call to
1104 in a handler for the signal may return the PID
1105 of the calling process ("the parent"),
1106 if the clone wrapper has not yet had a chance to update the PID
1108 (This discussion ignores the case where the child was created using
1113 return the same value in the child and in the process that called
1115 since the caller and the child are in the same thread group.
1116 The stale-cache problem also does not occur if the
1120 To get the truth, it may be necessary to use code such as the following:
1123 #include <syscall.h>
1127 mypid = syscall(SYS_getpid);
1129 .\" See also the following bug reports
1130 .\" https://bugzilla.redhat.com/show_bug.cgi?id=417521
1131 .\" http://sourceware.org/bugzilla/show_bug.cgi?id=6910
1133 The following program demonstrates the use of
1135 to create a child process that executes in a separate UTS namespace.
1136 The child changes the hostname in its UTS namespace.
1137 Both parent and child then display the system hostname,
1138 making it possible to see that the hostname
1139 differs in the UTS namespaces of the parent and child.
1140 For an example of the use of this program, see
1145 #include <sys/wait.h>
1146 #include <sys/utsname.h>
1153 #define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \\
1156 static int /* Start function for cloned child */
1157 childFunc(void *arg)
1161 /* Change hostname in UTS namespace of child */
1163 if (sethostname(arg, strlen(arg)) == \-1)
1164 errExit("sethostname");
1166 /* Retrieve and display hostname */
1168 if (uname(&uts) == \-1)
1170 printf("uts.nodename in child: %s\\n", uts.nodename);
1172 /* Keep the namespace open for a while, by sleeping.
1173 This allows some experimentation\-\-for example, another
1174 process might join the namespace. */
1178 return 0; /* Child terminates now */
1181 #define STACK_SIZE (1024 * 1024) /* Stack size for cloned child */
1184 main(int argc, char *argv[])
1186 char *stack; /* Start of stack buffer */
1187 char *stackTop; /* End of stack buffer */
1192 fprintf(stderr, "Usage: %s <child\-hostname>\\n", argv[0]);
1196 /* Allocate stack for child */
1198 stack = malloc(STACK_SIZE);
1201 stackTop = stack + STACK_SIZE; /* Assume stack grows downward */
1203 /* Create child that has its own UTS namespace;
1204 child commences execution in childFunc() */
1206 pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]);
1209 printf("clone() returned %ld\\n", (long) pid);
1211 /* Parent falls through to here */
1213 sleep(1); /* Give child time to change its hostname */
1215 /* Display hostname in parent\(aqs UTS namespace. This will be
1216 different from hostname in child\(aqs UTS namespace. */
1218 if (uname(&uts) == \-1)
1220 printf("uts.nodename in parent: %s\\n", uts.nodename);
1222 if (waitpid(pid, NULL, 0) == \-1) /* Wait for child */
1224 printf("child has terminated\\n");
1235 .BR set_thread_area (2),
1236 .BR set_tid_address (2),
1242 .BR capabilities (7),