1FORK(2) Linux Programmer's Manual FORK(2)
2
3
4
6 fork - create a child process
7
9 #include <sys/types.h>
10 #include <unistd.h>
11
12 pid_t fork(void);
13
15 fork() creates a new process by duplicating the calling process. The
16 new process is referred to as the child process. The calling process
17 is referred to as the parent process.
18
19 The child process and the parent process run in separate memory spaces.
20 At the time of fork() both memory spaces have the same content. Memory
21 writes, file mappings (mmap(2)), and unmappings (munmap(2)) performed
22 by one of the processes do not affect the other.
23
24 The child process is an exact duplicate of the parent process except
25 for the following points:
26
27 * The child has its own unique process ID, and this PID does not match
28 the ID of any existing process group (setpgid(2)) or session.
29
30 * The child's parent process ID is the same as the parent's process
31 ID.
32
33 * The child does not inherit its parent's memory locks (mlock(2),
34 mlockall(2)).
35
36 * Process resource utilizations (getrusage(2)) and CPU time counters
37 (times(2)) are reset to zero in the child.
38
39 * The child's set of pending signals is initially empty (sigpend‐
40 ing(2)).
41
42 * The child does not inherit semaphore adjustments from its parent
43 (semop(2)).
44
45 * The child does not inherit process-associated record locks from its
46 parent (fcntl(2)). (On the other hand, it does inherit fcntl(2)
47 open file description locks and flock(2) locks from its parent.)
48
49 * The child does not inherit timers from its parent (setitimer(2),
50 alarm(2), timer_create(2)).
51
52 * The child does not inherit outstanding asynchronous I/O operations
53 from its parent (aio_read(3), aio_write(3)), nor does it inherit any
54 asynchronous I/O contexts from its parent (see io_setup(2)).
55
56 The process attributes in the preceding list are all specified in
57 POSIX.1. The parent and child also differ with respect to the follow‐
58 ing Linux-specific process attributes:
59
60 * The child does not inherit directory change notifications (dnotify)
61 from its parent (see the description of F_NOTIFY in fcntl(2)).
62
63 * The prctl(2) PR_SET_PDEATHSIG setting is reset so that the child
64 does not receive a signal when its parent terminates.
65
66 * The default timer slack value is set to the parent's current timer
67 slack value. See the description of PR_SET_TIMERSLACK in prctl(2).
68
69 * Memory mappings that have been marked with the madvise(2) MADV_DONT‐
70 FORK flag are not inherited across a fork().
71
72 * Memory in address ranges that have been marked with the madvise(2)
73 MADV_WIPEONFORK flag is zeroed in the child after a fork(). (The
74 MADV_WIPEONFORK setting remains in place for those address ranges in
75 the child.)
76
77 * The termination signal of the child is always SIGCHLD (see
78 clone(2)).
79
80 * The port access permission bits set by ioperm(2) are not inherited
81 by the child; the child must turn on any bits that it requires using
82 ioperm(2).
83
84 Note the following further points:
85
86 * The child process is created with a single thread—the one that
87 called fork(). The entire virtual address space of the parent is
88 replicated in the child, including the states of mutexes, condition
89 variables, and other pthreads objects; the use of pthread_atfork(3)
90 may be helpful for dealing with problems that this can cause.
91
92 * After a fork() in a multithreaded program, the child can safely call
93 only async-signal-safe functions (see signal-safety(7)) until such
94 time as it calls execve(2).
95
96 * The child inherits copies of the parent's set of open file descrip‐
97 tors. Each file descriptor in the child refers to the same open
98 file description (see open(2)) as the corresponding file descriptor
99 in the parent. This means that the two file descriptors share open
100 file status flags, file offset, and signal-driven I/O attributes
101 (see the description of F_SETOWN and F_SETSIG in fcntl(2)).
102
103 * The child inherits copies of the parent's set of open message queue
104 descriptors (see mq_overview(7)). Each file descriptor in the child
105 refers to the same open message queue description as the correspond‐
106 ing file descriptor in the parent. This means that the two file de‐
107 scriptors share the same flags (mq_flags).
108
109 * The child inherits copies of the parent's set of open directory
110 streams (see opendir(3)). POSIX.1 says that the corresponding di‐
111 rectory streams in the parent and child may share the directory
112 stream positioning; on Linux/glibc they do not.
113
115 On success, the PID of the child process is returned in the parent, and
116 0 is returned in the child. On failure, -1 is returned in the parent,
117 no child process is created, and errno is set appropriately.
118
120 EAGAIN A system-imposed limit on the number of threads was encountered.
121 There are a number of limits that may trigger this error:
122
123 * the RLIMIT_NPROC soft resource limit (set via setrlimit(2)),
124 which limits the number of processes and threads for a real
125 user ID, was reached;
126
127 * the kernel's system-wide limit on the number of processes and
128 threads, /proc/sys/kernel/threads-max, was reached (see
129 proc(5));
130
131 * the maximum number of PIDs, /proc/sys/kernel/pid_max, was
132 reached (see proc(5)); or
133
134 * the PID limit (pids.max) imposed by the cgroup "process num‐
135 ber" (PIDs) controller was reached.
136
137 EAGAIN The caller is operating under the SCHED_DEADLINE scheduling pol‐
138 icy and does not have the reset-on-fork flag set. See sched(7).
139
140 ENOMEM fork() failed to allocate the necessary kernel structures be‐
141 cause memory is tight.
142
143 ENOMEM An attempt was made to create a child process in a PID namespace
144 whose "init" process has terminated. See pid_namespaces(7).
145
146 ENOSYS fork() is not supported on this platform (for example, hardware
147 without a Memory-Management Unit).
148
149 ERESTARTNOINTR (since Linux 2.6.17)
150 System call was interrupted by a signal and will be restarted.
151 (This can be seen only during a trace.)
152
154 POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.
155
157 Under Linux, fork() is implemented using copy-on-write pages, so the
158 only penalty that it incurs is the time and memory required to dupli‐
159 cate the parent's page tables, and to create a unique task structure
160 for the child.
161
162 C library/kernel differences
163 Since version 2.3.3, rather than invoking the kernel's fork() system
164 call, the glibc fork() wrapper that is provided as part of the NPTL
165 threading implementation invokes clone(2) with flags that provide the
166 same effect as the traditional system call. (A call to fork() is
167 equivalent to a call to clone(2) specifying flags as just SIGCHLD.)
168 The glibc wrapper invokes any fork handlers that have been established
169 using pthread_atfork(3).
170
172 See pipe(2) and wait(2).
173
175 clone(2), execve(2), exit(2), setrlimit(2), unshare(2), vfork(2),
176 wait(2), daemon(3), pthread_atfork(3), capabilities(7), credentials(7)
177
179 This page is part of release 5.10 of the Linux man-pages project. A
180 description of the project, information about reporting bugs, and the
181 latest version of this page, can be found at
182 https://www.kernel.org/doc/man-pages/.
183
184
185
186Linux 2020-06-09 FORK(2)