]> git.ipfire.org Git - thirdparty/man-pages.git/blob - man2/clone.2
20be9675bc7eeee73efe292396285f98bf8e2256
[thirdparty/man-pages.git] / man2 / clone.2
1 .\" Copyright (c) 1992 Drew Eckhardt <drew@cs.colorado.edu>, March 28, 1992
2 .\" and Copyright (c) Michael Kerrisk, 2001, 2002, 2005, 2013
3 .\"
4 .\" %%%LICENSE_START(GPL_NOVERSION_ONELINE)
5 .\" May be distributed under the GNU General Public License.
6 .\" %%%LICENSE_END
7 .\"
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
41 .\"
42 .TH CLONE 2 2017-09-15 "Linux" "Linux Programmer's Manual"
43 .SH NAME
44 clone, __clone2 \- create a child process
45 .SH SYNOPSIS
46 .nf
47 /* Prototype for the glibc wrapper function */
48 .PP
49 .B #define _GNU_SOURCE
50 .B #include <sched.h>
51 .PP
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 " */ );"
56 .PP
57 /* For the prototype of the raw system call, see NOTES */
58 .fi
59 .SH DESCRIPTION
60 .BR clone ()
61 creates a new process, in a manner similar to
62 .BR fork (2).
63 .PP
64 This page describes both the glibc
65 .BR clone ()
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.
70 .PP
71 Unlike
72 .BR fork (2),
73 .BR clone ()
74 allows the child process to share parts of its execution context with
75 the calling process, such as the virtual address 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
80 .B CLONE_PARENT
81 below.)
82 .PP
83 One use of
84 .BR clone ()
85 is to implement threads: multiple flows of control in a program that
86 run concurrently in a shared address space.
87 .PP
88 When the child process is created with
89 .BR clone (),
90 it commences execution by calling the function pointed to by the argument
91 .IR fn .
92 (This differs from
93 .BR fork (2),
94 where execution continues in the child from the point
95 of the
96 .BR fork (2)
97 call.)
98 The
99 .I arg
100 argument is passed as the argument of the function
101 .IR fn .
102 .PP
103 When the
104 .IR fn ( arg )
105 function returns, the child process terminates.
106 The integer returned by
107 .I fn
108 is the exit status for the child process.
109 The child process may also terminate explicitly by calling
110 .BR exit (2)
111 or after receiving a fatal signal.
112 .PP
113 The
114 .I child_stack
115 argument specifies the location of the stack used by the child process.
116 Since the child and calling process may share memory,
117 it is not possible for the child process to execute in the
118 same stack as the calling process.
119 The calling process must therefore
120 set up memory space for the child stack and pass a pointer to this
121 space to
122 .BR clone ().
123 Stacks grow downward on all processors that run Linux
124 (except the HP PA processors), so
125 .I child_stack
126 usually points to the topmost address of the memory space set up for
127 the child stack.
128 .PP
129 The low byte of
130 .I flags
131 contains the number of the
132 .I "termination signal"
133 sent to the parent when the child dies.
134 If this signal is specified as anything other than
135 .BR SIGCHLD ,
136 then the parent process must specify the
137 .B __WALL
138 or
139 .B __WCLONE
140 options when waiting for the child with
141 .BR wait (2).
142 If no signal is specified, then the parent process is not signaled
143 when the child terminates.
144 .PP
145 .I flags
146 may also be bitwise-ORed with zero or more of the following constants,
147 in order to specify what is shared between the calling process
148 and the child process:
149 .TP
150 .BR CLONE_CHILD_CLEARTID " (since Linux 2.5.49)"
151 Clear (zero) the child thread ID at the location
152 .I ctid
153 in child memory when the child exits, and do a wakeup on the futex
154 at that address.
155 The address involved may be changed by the
156 .BR set_tid_address (2)
157 system call.
158 This is used by threading libraries.
159 .TP
160 .BR CLONE_CHILD_SETTID " (since Linux 2.5.49)"
161 Store the child thread ID at the location
162 .I ctid
163 in the child's memory.
164 The store operation completes before
165 .BR clone ()
166 returns control to user space.
167 .TP
168 .BR CLONE_FILES " (since Linux 2.0)"
169 If
170 .B CLONE_FILES
171 is set, the calling process and the child process share the same file
172 descriptor table.
173 Any file descriptor created by the calling process or by the child
174 process is also valid in the other process.
175 Similarly, if one of the processes closes a file descriptor,
176 or changes its associated flags (using the
177 .BR fcntl (2)
178 .B F_SETFD
179 operation), the other process is also affected.
180 If a process sharing a file descriptor table calls
181 .BR execve (2),
182 its file descriptor table is duplicated (unshared).
183 .IP
184 If
185 .B CLONE_FILES
186 is not set, the child process inherits a copy of all file descriptors
187 opened in the calling process at the time of
188 .BR clone ().
189 Subsequent operations that open or close file descriptors,
190 or change file descriptor flags,
191 performed by either the calling
192 process or the child process do not affect the other process.
193 Note, however,
194 that the duplicated file descriptors in the child refer to the same open file
195 descriptions as the corresponding file descriptors in the calling process,
196 and thus share file offsets and file status flags (see
197 .BR open (2)).
198 .TP
199 .BR CLONE_FS " (since Linux 2.0)"
200 If
201 .B CLONE_FS
202 is set, the caller and the child process share the same filesystem
203 information.
204 This includes the root of the filesystem, the current
205 working directory, and the umask.
206 Any call to
207 .BR chroot (2),
208 .BR chdir (2),
209 or
210 .BR umask (2)
211 performed by the calling process or the child process also affects the
212 other process.
213 .IP
214 If
215 .B CLONE_FS
216 is not set, the child process works on a copy of the filesystem
217 information of the calling process at the time of the
218 .BR clone ()
219 call.
220 Calls to
221 .BR chroot (2),
222 .BR chdir (2),
223 or
224 .BR umask (2)
225 performed later by one of the processes do not affect the other process.
226 .TP
227 .BR CLONE_IO " (since Linux 2.6.25)"
228 If
229 .B CLONE_IO
230 is set, then the new process shares an I/O context with
231 the calling process.
232 If this flag is not set, then (as with
233 .BR fork (2))
234 the new process has its own I/O context.
235 .IP
236 .\" The following based on text from Jens Axboe
237 The I/O context is the I/O scope of the disk scheduler (i.e.,
238 what the I/O scheduler uses to model scheduling of a process's I/O).
239 If processes share the same I/O context,
240 they are treated as one by the I/O scheduler.
241 As a consequence, they get to share disk time.
242 For some I/O schedulers,
243 .\" the anticipatory and CFQ scheduler
244 if two processes share an I/O context,
245 they will be allowed to interleave their disk access.
246 If several threads are doing I/O on behalf of the same process
247 .RB ( aio_read (3),
248 for instance), they should employ
249 .BR CLONE_IO
250 to get better I/O performance.
251 .\" with CFQ and AS.
252 .IP
253 If the kernel is not configured with the
254 .B CONFIG_BLOCK
255 option, this flag is a no-op.
256 .TP
257 .BR CLONE_NEWCGROUP " (since Linux 4.6)"
258 Create the process in a new cgroup namespace.
259 If this flag is not set, then (as with
260 .BR fork (2))
261 the process is created in the same cgroup namespaces as the calling process.
262 This flag is intended for the implementation of containers.
263 .IP
264 For further information on cgroup namespaces, see
265 .BR cgroup_namespaces (7).
266 .IP
267 Only a privileged process
268 .RB ( CAP_SYS_ADMIN )
269 can employ
270 .BR CLONE_NEWCGROUP .
271 .\"
272 .TP
273 .BR CLONE_NEWIPC " (since Linux 2.6.19)"
274 If
275 .B CLONE_NEWIPC
276 is set, then create the process in a new IPC namespace.
277 If this flag is not set, then (as with
278 .BR fork (2)),
279 the process is created in the same IPC namespace as
280 the calling process.
281 This flag is intended for the implementation of containers.
282 .IP
283 An IPC namespace provides an isolated view of System\ V IPC objects (see
284 .BR svipc (7))
285 and (since Linux 2.6.30)
286 .\" commit 7eafd7c74c3f2e67c27621b987b28397110d643f
287 .\" https://lwn.net/Articles/312232/
288 POSIX message queues
289 (see
290 .BR mq_overview (7)).
291 The common characteristic of these IPC mechanisms is that IPC
292 objects are identified by mechanisms other than filesystem
293 pathnames.
294 .IP
295 Objects created in an IPC namespace are visible to all other processes
296 that are members of that namespace,
297 but are not visible to processes in other IPC namespaces.
298 .IP
299 When an IPC namespace is destroyed
300 (i.e., when the last process that is a member of the namespace terminates),
301 all IPC objects in the namespace are automatically destroyed.
302 .IP
303 Only a privileged process
304 .RB ( CAP_SYS_ADMIN )
305 can employ
306 .BR CLONE_NEWIPC .
307 This flag can't be specified in conjunction with
308 .BR CLONE_SYSVSEM .
309 .IP
310 For further information on IPC namespaces, see
311 .BR namespaces (7).
312 .TP
313 .BR CLONE_NEWNET " (since Linux 2.6.24)"
314 (The implementation of this flag was completed only
315 by about kernel version 2.6.29.)
316 .IP
317 If
318 .B CLONE_NEWNET
319 is set, then create the process in a new network namespace.
320 If this flag is not set, then (as with
321 .BR fork (2))
322 the process is created in the same network namespace as
323 the calling process.
324 This flag is intended for the implementation of containers.
325 .IP
326 A network namespace provides an isolated view of the networking stack
327 (network device interfaces, IPv4 and IPv6 protocol stacks,
328 IP routing tables, firewall rules, the
329 .I /proc/net
330 and
331 .I /sys/class/net
332 directory trees, sockets, etc.).
333 A physical network device can live in exactly one
334 network namespace.
335 A virtual network
336 .RB ( veth (4))
337 device pair provides a pipe-like abstraction
338 that can be used to create tunnels between network namespaces,
339 and can be used to create a bridge to a physical network device
340 in another namespace.
341 .IP
342 When a network namespace is freed
343 (i.e., when the last process in the namespace terminates),
344 its physical network devices are moved back to the
345 initial network namespace (not to the parent of the process).
346 For further information on network namespaces, see
347 .BR namespaces (7).
348 .IP
349 Only a privileged process
350 .RB ( CAP_SYS_ADMIN )
351 can employ
352 .BR CLONE_NEWNET .
353 .TP
354 .BR CLONE_NEWNS " (since Linux 2.4.19)"
355 If
356 .B CLONE_NEWNS
357 is set, the cloned child is started in a new mount namespace,
358 initialized with a copy of the namespace of the parent.
359 If
360 .B CLONE_NEWNS
361 is not set, the child lives in the same mount
362 namespace as the parent.
363 .IP
364 Only a privileged process
365 .RB ( CAP_SYS_ADMIN )
366 can employ
367 .BR CLONE_NEWNS .
368 It is not permitted to specify both
369 .B CLONE_NEWNS
370 and
371 .B CLONE_FS
372 .\" See https://lwn.net/Articles/543273/
373 in the same
374 .BR clone ()
375 call.
376 .IP
377 For further information on mount namespaces, see
378 .BR namespaces (7)
379 and
380 .BR mount_namespaces (7).
381 .TP
382 .BR CLONE_NEWPID " (since Linux 2.6.24)"
383 .\" This explanation draws a lot of details from
384 .\" http://lwn.net/Articles/259217/
385 .\" Authors: Pavel Emelyanov <xemul@openvz.org>
386 .\" and Kir Kolyshkin <kir@openvz.org>
387 .\"
388 .\" The primary kernel commit is 30e49c263e36341b60b735cbef5ca37912549264
389 .\" Author: Pavel Emelyanov <xemul@openvz.org>
390 If
391 .B CLONE_NEWPID
392 is set, then create the process in a new PID namespace.
393 If this flag is not set, then (as with
394 .BR fork (2))
395 the process is created in the same PID namespace as
396 the calling process.
397 This flag is intended for the implementation of containers.
398 .IP
399 For further information on PID namespaces, see
400 .BR namespaces (7)
401 and
402 .BR pid_namespaces (7).
403 .IP
404 Only a privileged process
405 .RB ( CAP_SYS_ADMIN )
406 can employ
407 .BR CLONE_NEWPID .
408 This flag can't be specified in conjunction with
409 .BR CLONE_THREAD
410 or
411 .BR CLONE_PARENT .
412 .TP
413 .BR CLONE_NEWUSER
414 (This flag first became meaningful for
415 .BR clone ()
416 in Linux 2.6.23,
417 the current
418 .BR clone ()
419 semantics were merged in Linux 3.5,
420 and the final pieces to make the user namespaces completely usable were
421 merged in Linux 3.8.)
422 .IP
423 If
424 .B CLONE_NEWUSER
425 is set, then create the process in a new user namespace.
426 If this flag is not set, then (as with
427 .BR fork (2))
428 the process is created in the same user namespace as the calling process.
429 .IP
430 Before Linux 3.8, use of
431 .BR CLONE_NEWUSER
432 required that the caller have three capabilities:
433 .BR CAP_SYS_ADMIN ,
434 .BR CAP_SETUID ,
435 and
436 .BR CAP_SETGID .
437 .\" Before Linux 2.6.29, it appears that only CAP_SYS_ADMIN was needed
438 Starting with Linux 3.8,
439 no privileges are needed to create a user namespace.
440 .IP
441 This flag can't be specified in conjunction with
442 .BR CLONE_THREAD
443 or
444 .BR CLONE_PARENT .
445 For security reasons,
446 .\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71
447 .\" https://lwn.net/Articles/543273/
448 .\" The fix actually went into 3.9 and into 3.8.3. However, user namespaces
449 .\" were, for practical purposes, unusable in earlier 3.8.x because of the
450 .\" various filesystems that didn't support userns.
451 .BR CLONE_NEWUSER
452 cannot be specified in conjunction with
453 .BR CLONE_FS .
454 .IP
455 For further information on user namespaces, see
456 .BR namespaces (7)
457 and
458 .BR user_namespaces (7).
459 .TP
460 .BR CLONE_NEWUTS " (since Linux 2.6.19)"
461 If
462 .B CLONE_NEWUTS
463 is set, then create the process in a new UTS namespace,
464 whose identifiers are initialized by duplicating the identifiers
465 from the UTS namespace of the calling process.
466 If this flag is not set, then (as with
467 .BR fork (2))
468 the process is created in the same UTS namespace as
469 the calling process.
470 This flag is intended for the implementation of containers.
471 .IP
472 A UTS namespace is the set of identifiers returned by
473 .BR uname (2);
474 among these, the domain name and the hostname can be modified by
475 .BR setdomainname (2)
476 and
477 .BR sethostname (2),
478 respectively.
479 Changes made to the identifiers in a UTS namespace
480 are visible to all other processes in the same namespace,
481 but are not visible to processes in other UTS namespaces.
482 .IP
483 Only a privileged process
484 .RB ( CAP_SYS_ADMIN )
485 can employ
486 .BR CLONE_NEWUTS .
487 .IP
488 For further information on UTS namespaces, see
489 .BR namespaces (7).
490 .TP
491 .BR CLONE_PARENT " (since Linux 2.3.12)"
492 If
493 .B CLONE_PARENT
494 is set, then the parent of the new child (as returned by
495 .BR getppid (2))
496 will be the same as that of the calling process.
497 .IP
498 If
499 .B CLONE_PARENT
500 is not set, then (as with
501 .BR fork (2))
502 the child's parent is the calling process.
503 .IP
504 Note that it is the parent process, as returned by
505 .BR getppid (2),
506 which is signaled when the child terminates, so that
507 if
508 .B CLONE_PARENT
509 is set, then the parent of the calling process, rather than the
510 calling process itself, will be signaled.
511 .TP
512 .BR CLONE_PARENT_SETTID " (since Linux 2.5.49)"
513 Store the child thread ID at the location
514 .I ptid
515 in the parent's memory.
516 (In Linux 2.5.32-2.5.48 there was a flag
517 .B CLONE_SETTID
518 that did this.)
519 The store operation completes before
520 .BR clone ()
521 returns control to user space.
522 .TP
523 .BR CLONE_PID " (Linux 2.0 to 2.5.15)"
524 If
525 .B CLONE_PID
526 is set, the child process is created with the same process ID as
527 the calling process.
528 This is good for hacking the system, but otherwise
529 of not much use.
530 From Linux 2.3.21 onward, this flag could be
531 specified only by the system boot process (PID 0).
532 The flag disappeared completely from the kernel sources in Linux 2.5.16.
533 Since then, the kernel silently ignores this bit if it is specified in
534 .IR flags .
535 .TP
536 .BR CLONE_PTRACE " (since Linux 2.2)"
537 If
538 .B CLONE_PTRACE
539 is specified, and the calling process is being traced,
540 then trace the child also (see
541 .BR ptrace (2)).
542 .TP
543 .BR CLONE_SETTLS " (since Linux 2.5.32)"
544 The TLS (Thread Local Storage) descriptor is set to
545 .IR newtls .
546 .IP
547 The interpretation of
548 .I newtls
549 and the resulting effect is architecture dependent.
550 On x86,
551 .I newtls
552 is interpreted as a
553 .IR "struct user_desc\ *"
554 (see
555 .BR set_thread_area (2)).
556 On x86-64 it is the new value to be set for the %fs base register
557 (see the
558 .B ARCH_SET_FS
559 argument to
560 .BR arch_prctl (2)).
561 On architectures with a dedicated TLS register, it is the new value
562 of that register.
563 .TP
564 .BR CLONE_SIGHAND " (since Linux 2.0)"
565 If
566 .B CLONE_SIGHAND
567 is set, the calling process and the child process share the same table of
568 signal handlers.
569 If the calling process or child process calls
570 .BR sigaction (2)
571 to change the behavior associated with a signal, the behavior is
572 changed in the other process as well.
573 However, the calling process and child
574 processes still have distinct signal masks and sets of pending
575 signals.
576 So, one of them may block or unblock signals using
577 .BR sigprocmask (2)
578 without affecting the other process.
579 .IP
580 If
581 .B CLONE_SIGHAND
582 is not set, the child process inherits a copy of the signal handlers
583 of the calling process at the time
584 .BR clone ()
585 is called.
586 Calls to
587 .BR sigaction (2)
588 performed later by one of the processes have no effect on the other
589 process.
590 .IP
591 Since Linux 2.6.0-test6,
592 .I flags
593 must also include
594 .B CLONE_VM
595 if
596 .B CLONE_SIGHAND
597 is specified
598 .TP
599 .BR CLONE_STOPPED " (since Linux 2.6.0-test2)"
600 If
601 .B CLONE_STOPPED
602 is set, then the child is initially stopped (as though it was sent a
603 .B SIGSTOP
604 signal), and must be resumed by sending it a
605 .B SIGCONT
606 signal.
607 .IP
608 This flag was
609 .I deprecated
610 from Linux 2.6.25 onward,
611 and was
612 .I removed
613 altogether in Linux 2.6.38.
614 Since then, the kernel silently ignores it without error.
615 .\" glibc 2.8 removed this defn from bits/sched.h
616 Starting with Linux 4.6, the same bit was reused for the
617 .BR CLONE_NEWCGROUP
618 flag.
619 .TP
620 .BR CLONE_SYSVSEM " (since Linux 2.5.10)"
621 If
622 .B CLONE_SYSVSEM
623 is set, then the child and the calling process share
624 a single list of System V semaphore adjustment
625 .RI ( semadj )
626 values (see
627 .BR semop (2)).
628 In this case, the shared list accumulates
629 .I semadj
630 values across all processes sharing the list,
631 and semaphore adjustments are performed only when the last process
632 that is sharing the list terminates (or ceases sharing the list using
633 .BR unshare (2)).
634 If this flag is not set, then the child has a separate
635 .I semadj
636 list that is initially empty.
637 .TP
638 .BR CLONE_THREAD " (since Linux 2.4.0-test8)"
639 If
640 .B CLONE_THREAD
641 is set, the child is placed in the same thread group as the calling process.
642 To make the remainder of the discussion of
643 .B CLONE_THREAD
644 more readable, the term "thread" is used to refer to the
645 processes within a thread group.
646 .IP
647 Thread groups were a feature added in Linux 2.4 to support the
648 POSIX threads notion of a set of threads that share a single PID.
649 Internally, this shared PID is the so-called
650 thread group identifier (TGID) for the thread group.
651 Since Linux 2.4, calls to
652 .BR getpid (2)
653 return the TGID of the caller.
654 .IP
655 The threads within a group can be distinguished by their (system-wide)
656 unique thread IDs (TID).
657 A new thread's TID is available as the function result
658 returned to the caller of
659 .BR clone (),
660 and a thread can obtain
661 its own TID using
662 .BR gettid (2).
663 .IP
664 When a call is made to
665 .BR clone ()
666 without specifying
667 .BR CLONE_THREAD ,
668 then the resulting thread is placed in a new thread group
669 whose TGID is the same as the thread's TID.
670 This thread is the
671 .I leader
672 of the new thread group.
673 .IP
674 A new thread created with
675 .B CLONE_THREAD
676 has the same parent process as the caller of
677 .BR clone ()
678 (i.e., like
679 .BR CLONE_PARENT ),
680 so that calls to
681 .BR getppid (2)
682 return the same value for all of the threads in a thread group.
683 When a
684 .B CLONE_THREAD
685 thread terminates, the thread that created it using
686 .BR clone ()
687 is not sent a
688 .B SIGCHLD
689 (or other termination) signal;
690 nor can the status of such a thread be obtained
691 using
692 .BR wait (2).
693 (The thread is said to be
694 .IR detached .)
695 .IP
696 After all of the threads in a thread group terminate
697 the parent process of the thread group is sent a
698 .B SIGCHLD
699 (or other termination) signal.
700 .IP
701 If any of the threads in a thread group performs an
702 .BR execve (2),
703 then all threads other than the thread group leader are terminated,
704 and the new program is executed in the thread group leader.
705 .IP
706 If one of the threads in a thread group creates a child using
707 .BR fork (2),
708 then any thread in the group can
709 .BR wait (2)
710 for that child.
711 .IP
712 Since Linux 2.5.35,
713 .I flags
714 must also include
715 .B CLONE_SIGHAND
716 if
717 .B CLONE_THREAD
718 is specified
719 (and note that, since Linux 2.6.0-test6,
720 .BR CLONE_SIGHAND
721 also requires
722 .BR CLONE_VM
723 to be included).
724 .IP
725 Signals may be sent to a thread group as a whole (i.e., a TGID) using
726 .BR kill (2),
727 or to a specific thread (i.e., TID) using
728 .BR tgkill (2).
729 .IP
730 Signal dispositions and actions are process-wide:
731 if an unhandled signal is delivered to a thread, then
732 it will affect (terminate, stop, continue, be ignored in)
733 all members of the thread group.
734 .IP
735 Each thread has its own signal mask, as set by
736 .BR sigprocmask (2),
737 but signals can be pending either: for the whole process
738 (i.e., deliverable to any member of the thread group),
739 when sent with
740 .BR kill (2);
741 or for an individual thread, when sent with
742 .BR tgkill (2).
743 A call to
744 .BR sigpending (2)
745 returns a signal set that is the union of the signals pending for the
746 whole process and the signals that are pending for the calling thread.
747 .IP
748 If
749 .BR kill (2)
750 is used to send a signal to a thread group,
751 and the thread group has installed a handler for the signal, then
752 the handler will be invoked in exactly one, arbitrarily selected
753 member of the thread group that has not blocked the signal.
754 If multiple threads in a group are waiting to accept the same signal using
755 .BR sigwaitinfo (2),
756 the kernel will arbitrarily select one of these threads
757 to receive a signal sent using
758 .BR kill (2).
759 .TP
760 .BR CLONE_UNTRACED " (since Linux 2.5.46)"
761 If
762 .B CLONE_UNTRACED
763 is specified, then a tracing process cannot force
764 .B CLONE_PTRACE
765 on this child process.
766 .TP
767 .BR CLONE_VFORK " (since Linux 2.2)"
768 If
769 .B CLONE_VFORK
770 is set, the execution of the calling process is suspended
771 until the child releases its virtual memory
772 resources via a call to
773 .BR execve (2)
774 or
775 .BR _exit (2)
776 (as with
777 .BR vfork (2)).
778 .IP
779 If
780 .B CLONE_VFORK
781 is not set, then both the calling process and the child are schedulable
782 after the call, and an application should not rely on execution occurring
783 in any particular order.
784 .TP
785 .BR CLONE_VM " (since Linux 2.0)"
786 If
787 .B CLONE_VM
788 is set, the calling process and the child process run in the same memory
789 space.
790 In particular, memory writes performed by the calling process
791 or by the child process are also visible in the other process.
792 Moreover, any memory mapping or unmapping performed with
793 .BR mmap (2)
794 or
795 .BR munmap (2)
796 by the child or calling process also affects the other process.
797 .IP
798 If
799 .B CLONE_VM
800 is not set, the child process runs in a separate copy of the memory
801 space of the calling process at the time of
802 .BR clone ().
803 Memory writes or file mappings/unmappings performed by one of the
804 processes do not affect the other, as with
805 .BR fork (2).
806 .SH NOTES
807 Note that the glibc
808 .BR clone ()
809 wrapper function makes some changes
810 in the memory pointed to by
811 .I child_stack
812 (changes required to set the stack up correctly for the child)
813 .I before
814 invoking the
815 .BR clone ()
816 system call.
817 So, in cases where
818 .BR clone ()
819 is used to recursively create children,
820 do not use the buffer employed for the parent's stack
821 as the stack of the child.
822 .\"
823 .SS C library/kernel differences
824 The raw
825 .BR clone ()
826 system call corresponds more closely to
827 .BR fork (2)
828 in that execution in the child continues from the point of the
829 call.
830 As such, the
831 .I fn
832 and
833 .I arg
834 arguments of the
835 .BR clone ()
836 wrapper function are omitted.
837 .PP
838 Another difference for the raw
839 .BR clone ()
840 system call is that the
841 .I child_stack
842 argument may be zero,
843 in which case the child uses a duplicate of the parent's stack.
844 (Copy-on-write semantics ensure that the child gets separate copies
845 of stack pages when either process modifies the stack.)
846 In this case, for correct operation, the
847 .B CLONE_VM
848 option should not be specified.
849 (If the child
850 .I shares
851 the parent's memory because of the use of the
852 .BR CLONE_VM
853 flag,
854 then no copy-on-write duplication occurs and chaos is likely to result.)
855 .PP
856 The order of the arguments also differs in the raw system call,
857 and there are variations in the arguments across architectures,
858 as detailed in the following paragraphs.
859 .PP
860 The raw system call interface on x86-64 and some other architectures
861 (including sh, tile, and alpha) is roughly:
862 .PP
863 .in +4
864 .EX
865 .BI "long clone(unsigned long " flags ", void *" child_stack ,
866 .BI " int *" ptid ", int *" ctid ,
867 .BI " unsigned long " newtls );
868 .EE
869 .in
870 .PP
871 On x86-32, and several other common architectures
872 (including score, ARM, ARM 64, PA-RISC, arc, Power PC, xtensa,
873 and MIPS),
874 .\" CONFIG_CLONE_BACKWARDS
875 the order of the last two arguments is reversed:
876 .PP
877 .in +4
878 .EX
879 .BI "long clone(unsigned long " flags ", void *" child_stack ,
880 .BI " int *" ptid ", unsigned long " newtls ,
881 .BI " int *" ctid );
882 .EE
883 .in
884 .PP
885 On the cris and s390 architectures,
886 .\" CONFIG_CLONE_BACKWARDS2
887 the order of the first two arguments is reversed:
888 .PP
889 .in +4
890 .EX
891 .BI "long clone(void *" child_stack ", unsigned long " flags ,
892 .BI " int *" ptid ", int *" ctid ,
893 .BI " unsigned long " newtls );
894 .EE
895 .in
896 .PP
897 On the microblaze architecture,
898 .\" CONFIG_CLONE_BACKWARDS3
899 an additional argument is supplied:
900 .PP
901 .in +4
902 .EX
903 .BI "long clone(unsigned long " flags ", void *" child_stack ,
904 .BI " int " stack_size , "\fR /* Size of stack */"
905 .BI " int *" ptid ", int *" ctid ,
906 .BI " unsigned long " newtls );
907 .EE
908 .in
909 .\"
910 .SS blackfin, m68k, and sparc
911 .\" Mike Frysinger noted in a 2013 mail:
912 .\" these arches don't define __ARCH_WANT_SYS_CLONE:
913 .\" blackfin ia64 m68k sparc
914 The argument-passing conventions on
915 blackfin, m68k, and sparc are different from the descriptions above.
916 For details, see the kernel (and glibc) source.
917 .SS ia64
918 On ia64, a different interface is used:
919 .PP
920 .nf
921 .BI "int __clone2(int (*" "fn" ")(void *), "
922 .BI " void *" child_stack_base ", size_t " stack_size ,
923 .BI " int " flags ", void *" "arg" ", ... "
924 .BI " /* pid_t *" ptid ", struct user_desc *" tls \
925 ", pid_t *" ctid " */ );"
926 .fi
927 .PP
928 The prototype shown above is for the glibc wrapper function;
929 the raw system call interface has no
930 .I fn
931 or
932 .I arg
933 argument, and changes the order of the arguments so that
934 .I flags
935 is the first argument, and
936 .I tls
937 is the last argument.
938 .PP
939 .BR __clone2 ()
940 operates in the same way as
941 .BR clone (),
942 except that
943 .I child_stack_base
944 points to the lowest address of the child's stack area,
945 and
946 .I stack_size
947 specifies the size of the stack pointed to by
948 .IR child_stack_base .
949 .SS Linux 2.4 and earlier
950 In Linux 2.4 and earlier,
951 .BR clone ()
952 does not take arguments
953 .IR ptid ,
954 .IR tls ,
955 and
956 .IR ctid .
957 .SH RETURN VALUE
958 .\" gettid(2) returns current->pid;
959 .\" getpid(2) returns current->tgid;
960 On success, the thread ID of the child process is returned
961 in the caller's thread of execution.
962 On failure, \-1 is returned
963 in the caller's context, no child process will be created, and
964 .I errno
965 will be set appropriately.
966 .SH ERRORS
967 .TP
968 .B EAGAIN
969 Too many processes are already running; see
970 .BR fork (2).
971 .TP
972 .B EINVAL
973 .B CLONE_SIGHAND
974 was specified, but
975 .B CLONE_VM
976 was not.
977 (Since Linux 2.6.0-test6.)
978 .TP
979 .B EINVAL
980 .B CLONE_THREAD
981 was specified, but
982 .B CLONE_SIGHAND
983 was not.
984 (Since Linux 2.5.35.)
985 .\" .TP
986 .\" .B EINVAL
987 .\" Precisely one of
988 .\" .B CLONE_DETACHED
989 .\" and
990 .\" .B CLONE_THREAD
991 .\" was specified.
992 .\" (Since Linux 2.6.0-test6.)
993 .TP
994 .B EINVAL
995 .\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71
996 Both
997 .B CLONE_FS
998 and
999 .B CLONE_NEWNS
1000 were specified in
1001 .IR flags .
1002 .TP
1003 .BR EINVAL " (since Linux 3.9)"
1004 Both
1005 .B CLONE_NEWUSER
1006 and
1007 .B CLONE_FS
1008 were specified in
1009 .IR flags .
1010 .TP
1011 .B EINVAL
1012 Both
1013 .B CLONE_NEWIPC
1014 and
1015 .B CLONE_SYSVSEM
1016 were specified in
1017 .IR flags .
1018 .TP
1019 .B EINVAL
1020 One (or both) of
1021 .BR CLONE_NEWPID
1022 or
1023 .BR CLONE_NEWUSER
1024 and one (or both) of
1025 .BR CLONE_THREAD
1026 or
1027 .BR CLONE_PARENT
1028 were specified in
1029 .IR flags .
1030 .TP
1031 .B EINVAL
1032 Returned by the glibc
1033 .BR clone ()
1034 wrapper function when
1035 .IR fn
1036 or
1037 .IR child_stack
1038 is specified as NULL.
1039 .TP
1040 .B EINVAL
1041 .BR CLONE_NEWIPC
1042 was specified in
1043 .IR flags ,
1044 but the kernel was not configured with the
1045 .B CONFIG_SYSVIPC
1046 and
1047 .BR CONFIG_IPC_NS
1048 options.
1049 .TP
1050 .B EINVAL
1051 .BR CLONE_NEWNET
1052 was specified in
1053 .IR flags ,
1054 but the kernel was not configured with the
1055 .B CONFIG_NET_NS
1056 option.
1057 .TP
1058 .B EINVAL
1059 .BR CLONE_NEWPID
1060 was specified in
1061 .IR flags ,
1062 but the kernel was not configured with the
1063 .B CONFIG_PID_NS
1064 option.
1065 .TP
1066 .B EINVAL
1067 .BR CLONE_NEWUTS
1068 was specified in
1069 .IR flags ,
1070 but the kernel was not configured with the
1071 .B CONFIG_UTS
1072 option.
1073 .TP
1074 .B EINVAL
1075 .I child_stack
1076 is not aligned to a suitable boundary for this architecture.
1077 For example, on aarch64,
1078 .I child_stack
1079 must be a multiple of 16.
1080 .TP
1081 .B ENOMEM
1082 Cannot allocate sufficient memory to allocate a task structure for the
1083 child, or to copy those parts of the caller's context that need to be
1084 copied.
1085 .TP
1086 .BR ENOSPC " (since Linux 3.7)"
1087 .\" commit f2302505775fd13ba93f034206f1e2a587017929
1088 .B CLONE_NEWPID
1089 was specified in flags,
1090 but the limit on the nesting depth of PID namespaces
1091 would have been exceeded; see
1092 .BR pid_namespaces (7).
1093 .TP
1094 .BR ENOSPC " (since Linux 4.9; beforehand " EUSERS )
1095 .B CLONE_NEWUSER
1096 was specified in
1097 .IR flags ,
1098 and the call would cause the limit on the number of
1099 nested user namespaces to be exceeded.
1100 See
1101 .BR user_namespaces (7).
1102 .IP
1103 From Linux 3.11 to Linux 4.8, the error diagnosed in this case was
1104 .BR EUSERS .
1105 .TP
1106 .BR ENOSPC " (since Linux 4.9)"
1107 One of the values in
1108 .I flags
1109 specified the creation of a new user namespace,
1110 but doing so would have caused the limit defined by the corresponding file in
1111 .IR /proc/sys/user
1112 to be exceeded.
1113 For further details, see
1114 .BR namespaces (7).
1115 .TP
1116 .B EPERM
1117 .BR CLONE_NEWCGROUP ,
1118 .BR CLONE_NEWIPC ,
1119 .BR CLONE_NEWNET ,
1120 .BR CLONE_NEWNS ,
1121 .BR CLONE_NEWPID ,
1122 or
1123 .BR CLONE_NEWUTS
1124 was specified by an unprivileged process (process without \fBCAP_SYS_ADMIN\fP).
1125 .TP
1126 .B EPERM
1127 .B CLONE_PID
1128 was specified by a process other than process 0.
1129 (This error occurs only on Linux 2.5.15 and earlier.)
1130 .TP
1131 .B EPERM
1132 .BR CLONE_NEWUSER
1133 was specified in
1134 .IR flags ,
1135 but either the effective user ID or the effective group ID of the caller
1136 does not have a mapping in the parent namespace (see
1137 .BR user_namespaces (7)).
1138 .TP
1139 .BR EPERM " (since Linux 3.9)"
1140 .\" commit 3151527ee007b73a0ebd296010f1c0454a919c7d
1141 .B CLONE_NEWUSER
1142 was specified in
1143 .I flags
1144 and the caller is in a chroot environment
1145 .\" FIXME What is the rationale for this restriction?
1146 (i.e., the caller's root directory does not match the root directory
1147 of the mount namespace in which it resides).
1148 .TP
1149 .BR ERESTARTNOINTR " (since Linux 2.6.17)"
1150 .\" commit 4a2c7a7837da1b91468e50426066d988050e4d56
1151 System call was interrupted by a signal and will be restarted.
1152 (This can be seen only during a trace.)
1153 .TP
1154 .BR EUSERS " (Linux 3.11 to Linux 4.8)"
1155 .B CLONE_NEWUSER
1156 was specified in
1157 .IR flags ,
1158 and the limit on the number of nested user namespaces would be exceeded.
1159 See the discussion of the
1160 .BR ENOSPC
1161 error above.
1162 .\" .SH VERSIONS
1163 .\" There is no entry for
1164 .\" .BR clone ()
1165 .\" in libc5.
1166 .\" glibc2 provides
1167 .\" .BR clone ()
1168 .\" as described in this manual page.
1169 .SH CONFORMING TO
1170 .BR clone ()
1171 is Linux-specific and should not be used in programs
1172 intended to be portable.
1173 .SH NOTES
1174 The
1175 .BR kcmp (2)
1176 system call can be used to test whether two processes share various
1177 resources such as a file descriptor table,
1178 System V semaphore undo operations, or a virtual address space.
1179 .PP
1180 .PP
1181 Handlers registered using
1182 .BR pthread_atfork (3)
1183 are not executed during a call to
1184 .BR clone ().
1185 .PP
1186 In the Linux 2.4.x series,
1187 .B CLONE_THREAD
1188 generally does not make the parent of the new thread the same
1189 as the parent of the calling process.
1190 However, for kernel versions 2.4.7 to 2.4.18 the
1191 .B CLONE_THREAD
1192 flag implied the
1193 .B CLONE_PARENT
1194 flag (as in Linux 2.6.0 and later).
1195 .PP
1196 For a while there was
1197 .B CLONE_DETACHED
1198 (introduced in 2.5.32):
1199 parent wants no child-exit signal.
1200 In Linux 2.6.2, the need to give this flag together with
1201 .B CLONE_THREAD
1202 disappeared.
1203 This flag is still defined, but has no effect.
1204 .PP
1205 On i386,
1206 .BR clone ()
1207 should not be called through vsyscall, but directly through
1208 .IR "int $0x80" .
1209 .SH BUGS
1210 GNU C library versions 2.3.4 up to and including 2.24
1211 contained a wrapper function for
1212 .BR getpid (2)
1213 that performed caching of PIDs.
1214 This caching relied on support in the glibc wrapper for
1215 .BR clone (),
1216 but limitations in the implementation
1217 meant that the cache was not up to date in some circumstances.
1218 In particular,
1219 if a signal was delivered to the child immediately after the
1220 .BR clone ()
1221 call, then a call to
1222 .BR getpid (2)
1223 in a handler for the signal could return the PID
1224 of the calling process ("the parent"),
1225 if the clone wrapper had not yet had a chance to update the PID
1226 cache in the child.
1227 (This discussion ignores the case where the child was created using
1228 .BR CLONE_THREAD ,
1229 when
1230 .BR getpid (2)
1231 .I should
1232 return the same value in the child and in the process that called
1233 .BR clone (),
1234 since the caller and the child are in the same thread group.
1235 The stale-cache problem also does not occur if the
1236 .I flags
1237 argument includes
1238 .BR CLONE_VM .)
1239 To get the truth, it was sometimes necessary to use code such as the following:
1240 .PP
1241 .in +4n
1242 .EX
1243 #include <syscall.h>
1244
1245 pid_t mypid;
1246
1247 mypid = syscall(SYS_getpid);
1248 .EE
1249 .in
1250 .\" See also the following bug reports
1251 .\" https://bugzilla.redhat.com/show_bug.cgi?id=417521
1252 .\" http://sourceware.org/bugzilla/show_bug.cgi?id=6910
1253 .PP
1254 Because of the stale-cache problem, as well as other problems noted in
1255 .BR getpid (2),
1256 the PID caching feature was removed in glibc 2.25.
1257 .SH EXAMPLE
1258 The following program demonstrates the use of
1259 .BR clone ()
1260 to create a child process that executes in a separate UTS namespace.
1261 The child changes the hostname in its UTS namespace.
1262 Both parent and child then display the system hostname,
1263 making it possible to see that the hostname
1264 differs in the UTS namespaces of the parent and child.
1265 For an example of the use of this program, see
1266 .BR setns (2).
1267 .SS Program source
1268 .EX
1269 #define _GNU_SOURCE
1270 #include <sys/wait.h>
1271 #include <sys/utsname.h>
1272 #include <sched.h>
1273 #include <string.h>
1274 #include <stdio.h>
1275 #include <stdlib.h>
1276 #include <unistd.h>
1277
1278 #define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \\
1279 } while (0)
1280
1281 static int /* Start function for cloned child */
1282 childFunc(void *arg)
1283 {
1284 struct utsname uts;
1285
1286 /* Change hostname in UTS namespace of child */
1287
1288 if (sethostname(arg, strlen(arg)) == \-1)
1289 errExit("sethostname");
1290
1291 /* Retrieve and display hostname */
1292
1293 if (uname(&uts) == \-1)
1294 errExit("uname");
1295 printf("uts.nodename in child: %s\\n", uts.nodename);
1296
1297 /* Keep the namespace open for a while, by sleeping.
1298 This allows some experimentation\-\-for example, another
1299 process might join the namespace. */
1300
1301 sleep(200);
1302
1303 return 0; /* Child terminates now */
1304 }
1305
1306 #define STACK_SIZE (1024 * 1024) /* Stack size for cloned child */
1307
1308 int
1309 main(int argc, char *argv[])
1310 {
1311 char *stack; /* Start of stack buffer */
1312 char *stackTop; /* End of stack buffer */
1313 pid_t pid;
1314 struct utsname uts;
1315
1316 if (argc < 2) {
1317 fprintf(stderr, "Usage: %s <child\-hostname>\\n", argv[0]);
1318 exit(EXIT_SUCCESS);
1319 }
1320
1321 /* Allocate stack for child */
1322
1323 stack = malloc(STACK_SIZE);
1324 if (stack == NULL)
1325 errExit("malloc");
1326 stackTop = stack + STACK_SIZE; /* Assume stack grows downward */
1327
1328 /* Create child that has its own UTS namespace;
1329 child commences execution in childFunc() */
1330
1331 pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]);
1332 if (pid == \-1)
1333 errExit("clone");
1334 printf("clone() returned %ld\\n", (long) pid);
1335
1336 /* Parent falls through to here */
1337
1338 sleep(1); /* Give child time to change its hostname */
1339
1340 /* Display hostname in parent\(aqs UTS namespace. This will be
1341 different from hostname in child\(aqs UTS namespace. */
1342
1343 if (uname(&uts) == \-1)
1344 errExit("uname");
1345 printf("uts.nodename in parent: %s\\n", uts.nodename);
1346
1347 if (waitpid(pid, NULL, 0) == \-1) /* Wait for child */
1348 errExit("waitpid");
1349 printf("child has terminated\\n");
1350
1351 exit(EXIT_SUCCESS);
1352 }
1353 .EE
1354 .SH SEE ALSO
1355 .BR fork (2),
1356 .BR futex (2),
1357 .BR getpid (2),
1358 .BR gettid (2),
1359 .BR kcmp (2),
1360 .BR set_thread_area (2),
1361 .BR set_tid_address (2),
1362 .BR setns (2),
1363 .BR tkill (2),
1364 .BR unshare (2),
1365 .BR wait (2),
1366 .BR capabilities (7),
1367 .BR namespaces (7),
1368 .BR pthreads (7)