1EXIT(3P)                   POSIX Programmer's Manual                  EXIT(3P)
2
3
4

PROLOG

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

NAME

12       exit, _Exit, _exit - terminate a process
13

SYNOPSIS

15       #include <stdlib.h>
16
17       void exit(int status);
18       void _Exit(int status);
19
20
21       #include <unistd.h>
22       void _exit(int status);
23
24

DESCRIPTION

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
31       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
35       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
43       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
48       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
53       The _Exit() and _exit() functions shall be functionally equivalent.
54
55       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
61       These functions shall terminate the calling process  with the following
62       consequences:
63
64       Note:  These consequences are all extensions to the ISO C standard  and
65              are not further CX shaded. However, XSI extensions are shaded.
66
67
68        * 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
72        * 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
80       The semantics of the waitid() function shall be equivalent to wait().
81
82        * 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
89       The semantics of the waitid() function shall be equivalent to wait().
90
91        * 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
95        * Either:
96
97       If the implementation supports the SIGCHLD signal, a SIGCHLD  shall  be
98       sent to the parent process.
99
100       Or:
101
102       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
107        * 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
112        * 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
116        * 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
120        * 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
124        * 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
128        * 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
133        * All open named semaphores in the calling process shall be closed  as
134          if by appropriate calls to sem_close().
135
136        * 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
143        * Memory mappings that were created in the process shall  be  unmapped
144          before the process is destroyed.
145
146        * 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
150        * All  open  message queue descriptors in the calling process shall be
151          closed as if by appropriate calls to mq_close().
152
153        * 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
161        * Threads terminated by a call to _Exit() or _exit() shall not  invoke
162          their cancellation cleanup handlers or per-thread data destructors.
163
164        * 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

RETURN VALUE

171       These functions do not return.
172

ERRORS

174       No errors are defined.
175
176       The following sections are informative.
177

EXAMPLES

179       None.
180

APPLICATION USAGE

182       Normally applications should use exit() rather than _Exit() or _exit().
183

RATIONALE

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
201       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
208       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
216       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
222   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
230       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
237       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
242       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
250       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
254       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
267       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
285       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
296       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
305       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

FUTURE DIRECTIONS

311       None.
312

SEE ALSO

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 .
329
330
331
332IEEE/The Open Group                  2003                             EXIT(3P)
Impressum