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