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