1_EXIT(3P) POSIX Programmer's Manual _EXIT(3P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
12 _Exit, _exit — terminate a process
13
15 #include <stdlib.h>
16 void _Exit(int status);
18 #include <unistd.h>
20 void _exit(int status);
22
24 For _Exit(): The functionality described on this reference page is
25 aligned with the ISO C standard. Any conflict between the requirements
26 described here and the ISO C standard is unintentional. This volume of
27 POSIX.1‐2017 defers to the ISO C standard.
28 The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, or any other
30 value, though only the least significant 8 bits (that is, status &
31 0377) shall be available from wait() and waitpid(); the full value
32 shall be available from waitid() and in the siginfo_t passed to a sig‐
33 nal handler for SIGCHLD.
34 The _Exit() and _exit() functions shall be functionally equivalent.
36 The _Exit() and _exit() functions shall not call functions registered
38 with atexit() nor any registered signal handlers. Open streams shall
39 not be flushed. Whether open streams are closed (without flushing) is
40 implementation-defined. Finally, the calling process shall be termi‐
41 nated with the consequences described below.
42 Consequences of Process Termination
44 Process termination caused by any reason shall have the following con‐
45 sequences:
46 Note: These consequences are all extensions to the ISO C standard
48 and are not further CX shaded. However, functionality relat‐
49 ing to the XSI option is shaded.
50 * All of the file descriptors, directory streams, conversion descrip‐
52 tors, and message catalog descriptors open in the calling process
53 shall be closed.
54 * If the parent process of the calling process has set its SA_NOCLD‐
56 WAIT flag or has set the action for the SIGCHLD signal to SIG_IGN:
57 -- The process' status information (see Section 2.13, Status
59 Information), if any, shall be discarded.
60 -- The lifetime of the calling process shall end immediately. If
62 SA_NOCLDWAIT is set, it is implementation-defined whether a
63 SIGCHLD signal is sent to the parent process.
64 -- If a thread in the parent process of the calling process is
66 blocked in wait(), waitpid(), or waitid(), and the parent
67 process has no remaining child processes in the set of waited-
68 for children, the wait(), waitid(), or waitpid() function shall
69 fail and set errno to [ECHILD].
70 Otherwise:
72 -- Status information (see Section 2.13, Status Information) shall
74 be generated.
75 -- The calling process shall be transformed into a zombie process.
77 Its status information shall be made available to the parent
78 process until the process' lifetime ends.
79 -- The process' lifetime shall end once its parent obtains the
81 process' status information via a currently-blocked or future
82 call to wait(), waitid() (without WNOWAIT), or waitpid().
83 -- If one or more threads in the parent process of the calling
85 process is blocked in a call to wait(), waitid(), or waitpid()
86 awaiting termination of the process, one (or, if any are call‐
87 ing waitid() with WNOWAIT, possibly more) of these threads
88 shall obtain the process' status information as specified in
89 Section 2.13, Status Information and become unblocked.
90 -- A SIGCHLD shall be sent to the parent process.
92 * Termination of a process does not directly terminate its children.
94 The sending of a SIGHUP signal as described below indirectly termi‐
95 nates children in some circumstances.
96 * The parent process ID of all of the existing child processes and
98 zombie processes of the calling process shall be set to the process
99 ID of an implementation-defined system process. That is, these pro‐
100 cesses shall be inherited by a special system process.
101 * Each attached shared-memory segment is detached and the value of
103 shm_nattch (see shmget()) in the data structure associated with its
104 shared memory ID shall be decremented by 1.
105 * For each semaphore for which the calling process has set a semadj
107 value (see semop()), that value shall be added to the semval of the
108 specified semaphore.
109 * If the process is a controlling process, the SIGHUP signal shall be
111 sent to each process in the foreground process group of the con‐
112 trolling terminal belonging to the calling process.
113 * If the process is a controlling process, the controlling terminal
115 associated with the session shall be disassociated from the ses‐
116 sion, allowing it to be acquired by a new controlling process.
117 * If the exit of the process causes a process group to become
119 orphaned, and if any member of the newly-orphaned process group is
120 stopped, then a SIGHUP signal followed by a SIGCONT signal shall be
121 sent to each process in the newly-orphaned process group.
122 * All open named semaphores in the calling process shall be closed as
124 if by appropriate calls to sem_close().
125 * Any memory locks established by the process via calls to mlockall()
127 or mlock() shall be removed. If locked pages in the address space
128 of the calling process are also mapped into the address spaces of
129 other processes and are locked by those processes, the locks estab‐
130 lished by the other processes shall be unaffected by the call by
131 this process to _Exit() or _exit().
132 * Memory mappings that were created in the process shall be unmapped
134 before the process is destroyed.
135 * Any blocks of typed memory that were mapped in the calling process
137 shall be unmapped, as if munmap() was implicitly called to unmap
138 them.
139 * All open message queue descriptors in the calling process shall be
141 closed as if by appropriate calls to mq_close().
142 * Any outstanding cancelable asynchronous I/O operations may be can‐
144 celed. Those asynchronous I/O operations that are not canceled
145 shall complete as if the _Exit() or _exit() operation had not yet
146 occurred, but any associated signal notifications shall be sup‐
147 pressed. The _Exit() or _exit() operation may block awaiting such
148 I/O completion. Whether any I/O is canceled, and which I/O may be
149 canceled upon _Exit() or _exit(), is implementation-defined.
150 * Threads terminated by a call to _Exit() or _exit() shall not invoke
152 their cancellation cleanup handlers or per-thread data destructors.
153 * If the calling process is a trace controller process, any trace
155 streams that were created by the calling process shall be shut down
156 as described by the posix_trace_shutdown() function, and mapping of
157 trace event names to trace event type identifiers of any process
158 built for these trace streams may be deallocated.
159
161 These functions do not return.
162
164 No errors are defined.
165 The following sections are informative.
167
169 None.
170
172 Normally applications should use exit() rather than _Exit() or _exit().
173
175 Process Termination
176 Early proposals drew a distinction between normal and abnormal process
177 termination. Abnormal termination was caused only by certain signals
178 and resulted in implementation-defined ``actions'', as discussed below.
179 Subsequent proposals distinguished three types of termination: normal
180 termination (as in the current specification), simple abnormal termina‐
181 tion, and abnormal termination with actions. Again the distinction
182 between the two types of abnormal termination was that they were caused
183 by different signals and that implementation-defined actions would
184 result in the latter case. Given that these actions were completely
185 implementation-defined, the early proposals were only saying when the
186 actions could occur and how their occurrence could be detected, but not
187 what they were. This was of little or no use to conforming applica‐
188 tions, and thus the distinction is not made in this volume of
189 POSIX.1‐2017.
190 The implementation-defined actions usually include, in most historical
192 implementations, the creation of a file named core in the current work‐
193 ing directory of the process. This file contains an image of the memory
194 of the process, together with descriptive information about the
195 process, perhaps sufficient to reconstruct the state of the process at
196 the receipt of the signal.
197 There is a potential security problem in creating a core file if the
199 process was set-user-ID and the current user is not the owner of the
200 program, if the process was set-group-ID and none of the user's groups
201 match the group of the program, or if the user does not have permission
202 to write in the current directory. In this situation, an implementation
203 either should not create a core file or should make it unreadable by
204 the user.
205 Despite the silence of this volume of POSIX.1‐2017 on this feature,
207 applications are advised not to create files named core because of
208 potential conflicts in many implementations. Some implementations use a
209 name other than core for the file; for example, by appending the
210 process ID to the filename.
211 Terminating a Process
213 It is important that the consequences of process termination as
214 described occur regardless of whether the process called _exit() (per‐
215 haps indirectly through exit()) or instead was terminated due to a sig‐
216 nal or for some other reason. Note that in the specific case of exit()
217 this means that the status argument to exit() is treated in the same
218 way as the status argument to _exit().
219 A language other than C may have other termination primitives than the
221 C-language exit() function, and programs written in such a language
222 should use its native termination primitives, but those should have as
223 part of their function the behavior of _exit() as described. Implemen‐
224 tations in languages other than C are outside the scope of this version
225 of this volume of POSIX.1‐2017, however.
226 As required by the ISO C standard, using return from main() has the
228 same behavior (other than with respect to language scope issues) as
229 calling exit() with the returned value. Reaching the end of the main()
230 function has the same behavior as calling exit(0).
231 A value of zero (or EXIT_SUCCESS, which is required to be zero) for the
233 argument status conventionally indicates successful termination. This
234 corresponds to the specification for exit() in the ISO C standard. The
235 convention is followed by utilities such as make and various shells,
236 which interpret a zero status from a child process as success. For this
237 reason, applications should not call exit(0) or _exit(0) when they ter‐
238 minate unsuccessfully; for example, in signal-catching functions.
239 Historically, the implementation-defined process that inherits children
241 whose parents have terminated without waiting on them is called init
242 and has a process ID of 1.
243 The sending of a SIGHUP to the foreground process group when a control‐
245 ling process terminates corresponds to somewhat different historical
246 implementations. In System V, the kernel sends a SIGHUP on termination
247 of (essentially) a controlling process. In 4.2 BSD, the kernel does not
248 send SIGHUP in a case like this, but the termination of a controlling
249 process is usually noticed by a system daemon, which arranges to send a
250 SIGHUP to the foreground process group with the vhangup() function.
251 However, in 4.2 BSD, due to the behavior of the shells that support job
252 control, the controlling process is usually a shell with no other pro‐
253 cesses in its process group. Thus, a change to make _exit() behave this
254 way in such systems should not cause problems with existing applica‐
255 tions.
256 The termination of a process may cause a process group to become
258 orphaned in either of two ways. The connection of a process group to
259 its parent(s) outside of the group depends on both the parents and
260 their children. Thus, a process group may be orphaned by the termina‐
261 tion of the last connecting parent process outside of the group or by
262 the termination of the last direct descendant of the parent
263 process(es). In either case, if the termination of a process causes a
264 process group to become orphaned, processes within the group are dis‐
265 connected from their job control shell, which no longer has any infor‐
266 mation on the existence of the process group. Stopped processes within
267 the group would languish forever. In order to avoid this problem, newly
268 orphaned process groups that contain stopped processes are sent a
269 SIGHUP signal and a SIGCONT signal to indicate that they have been dis‐
270 connected from their session. The SIGHUP signal causes the process
271 group members to terminate unless they are catching or ignoring SIGHUP.
272 Under most circumstances, all of the members of the process group are
273 stopped if any of them are stopped.
274 The action of sending a SIGHUP and a SIGCONT signal to members of a
276 newly orphaned process group is similar to the action of 4.2 BSD, which
277 sends SIGHUP and SIGCONT to each stopped child of an exiting process.
278 If such children exit in response to the SIGHUP, any additional descen‐
279 dants receive similar treatment at that time. In this volume of
280 POSIX.1‐2017, the signals are sent to the entire process group at the
281 same time. Also, in this volume of POSIX.1‐2017, but not in 4.2 BSD,
282 stopped processes may be orphaned, but may be members of a process
283 group that is not orphaned; therefore, the action taken at _exit() must
284 consider processes other than child processes.
285 It is possible for a process group to be orphaned by a call to
287 setpgid() or setsid(), as well as by process termination. This volume
288 of POSIX.1‐2017 does not require sending SIGHUP and SIGCONT in those
289 cases, because, unlike process termination, those cases are not caused
290 accidentally by applications that are unaware of job control. An imple‐
291 mentation can choose to send SIGHUP and SIGCONT in those cases as an
292 extension; such an extension must be documented as required in <sig‐
293 nal.h>.
294 The ISO/IEC 9899:1999 standard adds the _Exit() function that results
296 in immediate program termination without triggering signals or
297 atexit()-registered functions. In POSIX.1‐2008, this is equivalent to
298 the _exit() function.
299
301 None.
302
304 atexit(), exit(), mlock(), mlockall(), mq_close(), munmap(),
305 posix_trace_create(), sem_close(), semop(), setpgid(), setsid(),
306 shmget(), wait(), waitid()
307 The Base Definitions volume of POSIX.1‐2017, <stdlib.h>, <unistd.h>
309
311 Portions of this text are reprinted and reproduced in electronic form
312 from IEEE Std 1003.1-2017, Standard for Information Technology -- Por‐
313 table Operating System Interface (POSIX), The Open Group Base Specifi‐
314 cations Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of
315 Electrical and Electronics Engineers, Inc and The Open Group. In the
316 event of any discrepancy between this version and the original IEEE and
317 The Open Group Standard, the original IEEE and The Open Group Standard
318 is the referee document. The original Standard can be obtained online
319 at http://www.opengroup.org/unix/online.html .
320 Any typographical or formatting errors that appear in this page are
322 most likely to have been introduced during the conversion of the source
323 files to man page format. To report such errors, see https://www.ker‐
324 nel.org/doc/man-pages/reporting_bugs.html .
325IEEE/The Open Group 2017 _EXIT(3P)