1EXIT(3)                    Linux Programmer's Manual                   EXIT(3)
2
3
4

NAME

6       exit - cause normal process termination
7

SYNOPSIS

9       #include <stdlib.h>
10
11       void exit(int status);
12

DESCRIPTION

14       The  exit()  function  causes  normal process termination and the least
15       significant byte of status (i.e., status & 0xFF)  is  returned  to  the
16       parent (see wait(2)).
17
18       All  functions  registered with atexit(3) and on_exit(3) are called, in
19       the reverse order of their registration.  (It is possible  for  one  of
20       these  functions  to  use  atexit(3) or on_exit(3) to register an addi‐
21       tional function to be executed during exit processing; the  new  regis‐
22       tration  is  added to the front of the list of functions that remain to
23       be called.)  If one of these functions does not return (e.g., it  calls
24       _exit(2),  or  kills  itself with a signal), then none of the remaining
25       functions is called, and further exit processing (in particular, flush‐
26       ing  of  stdio(3) streams) is abandoned.  If a function has been regis‐
27       tered multiple times using atexit(3) or on_exit(3), then it  is  called
28       as many times as it was registered.
29
30       All  open  stdio(3)  streams  are flushed and closed.  Files created by
31       tmpfile(3) are removed.
32
33       The C standard specifies two constants, EXIT_SUCCESS and  EXIT_FAILURE,
34       that  may  be  passed  to exit() to indicate successful or unsuccessful
35       termination, respectively.
36

RETURN VALUE

38       The exit() function does not return.
39

ATTRIBUTES

41       For  an  explanation  of  the  terms  used   in   this   section,   see
42       attributes(7).
43
44       ┌──────────┬───────────────┬─────────────────────┐
45Interface Attribute     Value               
46       ├──────────┼───────────────┼─────────────────────┤
47exit()    │ Thread safety │ MT-Unsafe race:exit │
48       └──────────┴───────────────┴─────────────────────┘
49       The exit() function uses a global variable that is not protected, so it
50       is not thread-safe.
51

CONFORMING TO

53       POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
54

NOTES

56       The behavior is undefined if one  of  the  functions  registered  using
57       atexit(3)  and on_exit(3) calls either exit() or longjmp(3).  Note that
58       a call to execve(2) removes registrations created using  atexit(3)  and
59       on_exit(3).
60
61       The  use of EXIT_SUCCESS and EXIT_FAILURE is slightly more portable (to
62       non-UNIX environments) than the use of 0 and some nonzero value like  1
63       or -1.  In particular, VMS uses a different convention.
64
65       BSD  has  attempted  to  standardize exit codes (which some C libraries
66       such as the GNU C library have also  adopted);  see  the  file  <sysex‐
67       its.h>.
68
69       After  exit(),  the  exit  status  must  be  transmitted  to the parent
70       process.  There are three cases:
71
72       ·  If the parent has set SA_NOCLDWAIT, or has set the  SIGCHLD  handler
73          to SIG_IGN, the status is discarded and the child dies immediately.
74
75       ·  If  the  parent was waiting on the child, it is notified of the exit
76          status and the child dies immediately.
77
78       ·  Otherwise, the child becomes a "zombie" process: most of the process
79          resources  are  recycled,  but a slot containing minimal information
80          about the child process (termination status, resource usage  statis‐
81          tics)  is retained in process table.  This allows the parent to sub‐
82          sequently use waitpid(2) (or similar) to learn the termination  sta‐
83          tus of the child; at that point the zombie process slot is released.
84
85       If  the implementation supports the SIGCHLD signal, this signal is sent
86       to the parent.  If the parent has set  SA_NOCLDWAIT,  it  is  undefined
87       whether a SIGCHLD signal is sent.
88
89   Signals sent to other processes
90       If the exiting process is a session leader and its controlling terminal
91       is the controlling terminal of the session, then each  process  in  the
92       foreground  process group of this controlling terminal is sent a SIGHUP
93       signal, and the terminal is disassociated from this  session,  allowing
94       it to be acquired by a new controlling process.
95
96       If  the  exit of the process causes a process group to become orphaned,
97       and if any member of the newly orphaned process group is stopped,  then
98       a  SIGHUP  signal  followed  by  a  SIGCONT signal will be sent to each
99       process in this process group.  See setpgid(2) for  an  explanation  of
100       orphaned process groups.
101
102       Except  in  the above cases, where the signalled processes may be chil‐
103       dren of the terminating process, termination of a process does  not  in
104       general  cause  a  signal to be sent to children of that process.  How‐
105       ever, a process can use  the  prctl(2)  PR_SET_PDEATHSIG  operation  to
106       arrange that it receives a signal if its parent terminates.
107

SEE ALSO

109       _exit(2),    get_robust_list(2),    setpgid(2),   wait(2),   atexit(3),
110       on_exit(3), tmpfile(3)
111

COLOPHON

113       This page is part of release 5.07 of the Linux  man-pages  project.   A
114       description  of  the project, information about reporting bugs, and the
115       latest    version    of    this    page,    can     be     found     at
116       https://www.kernel.org/doc/man-pages/.
117
118
119
120Linux                             2020-02-09                           EXIT(3)
Impressum