1_EXIT(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
11

NAME

13       _Exit, _exit — terminate a process
14

SYNOPSIS

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

DESCRIPTION

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
30       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
34       The _Exit() and _exit() functions shall be functionally equivalent.
35
36       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
42   Consequences of Process Termination
43       Process  termination caused by any reason shall have the following con‐
44       sequences:
45
46       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
50        *  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
54        *  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
62           The semantics of the  waitid()  function  shall  be  equivalent  to
63           wait().
64
65        *  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
72           The semantics of the  waitid()  function  shall  be  equivalent  to
73           wait().
74
75        *  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
79        *  Either:
80
81           If  the implementation supports the SIGCHLD signal, a SIGCHLD shall
82           be sent to the parent process.
83
84           Or:
85
86           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
92        *  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
97        *  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
101        *  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
105        *  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
109        *  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
113        *  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
118        *  All open named semaphores in the calling process shall be closed as
119           if by appropriate calls to sem_close().
120
121        *  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
128        *  Memory mappings that were created in the process shall be  unmapped
129           before the process is destroyed.
130
131        *  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
135        *  All  open message queue descriptors in the calling process shall be
136           closed as if by appropriate calls to mq_close().
137
138        *  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
146        *  Threads terminated by a call to _Exit() or _exit() shall not invoke
147           their cancellation cleanup handlers or per-thread data destructors.
148
149        *  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

RETURN VALUE

156       These functions do not return.
157

ERRORS

159       No errors are defined.
160
161       The following sections are informative.
162

EXAMPLES

164       None.
165

APPLICATION USAGE

167       Normally applications should use exit() rather than _Exit() or _exit().
168

RATIONALE

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
186       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
193       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
201       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
207   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
215       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
222       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
227       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
235       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
239       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
252       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
270       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
281       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
290       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

FUTURE DIRECTIONS

296       None.
297

SEE ALSO

299       atexit(),   exit(),   mlock(),   mlockall(),   mq_close(),    munmap(),
300       posix_trace_create(),   sem_close(),   semop(),   setpgid(),  setsid(),
301       shmget(), wait(), waitid()
302
303       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
317       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 .
321
322
323
324IEEE/The Open Group                  2013                            _EXIT(3P)
Impressum