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