PROLOG This manual page is part of the POSIX Programmer
s Manual. The Linux implementation of this interface may
differ (consult the corresponding Linux manual page for
details of Linux behavior), or the interface may not be
implemented on Linux.

NAME exit, _Exit, _exit - terminate a process

SYNOPSIS #include <stdlib.h>

void exit(int status); void _Exit(int status);

#include <unistd.h> void _exit(int status);

DESCRIPTION For exit() and _Exit(): The functionality
described on this reference page is aligned with the ISO C
standard. Any conflict between the requirements described
here and the ISO C standard is unintentional. This volume of
IEEE Std 1003.1-2001 defers to the ISO C standard.

The value of status may be 0, EXIT_SUCCESS,
EXIT_FAILURE, or any other value, though only the least
significant 8 bits (that is, status & 0377) shall be
available to a waiting parent process.

The exit() function shall first call all functions
registered by atexit(), in the reverse order of their
registration, except that a function is called after any
previously registered functions that had already been called
at the time it was registered. Each function is called as
many times as it was registered. If, during the call to any
such function, a call to the longjmp() function is made that
would ter- minate the call to the registered function, the
behavior is undefined.

If a function registered by a call to atexit() fails to
return, the remaining registered functions shall not be
called and the rest of the exit() processing shall not be
completed. If exit() is called more than once, the behavior
is undefined.

The exit() function shall then flush all open streams
with unwritten buffered data, close all open streams, and
remove all files created by tmpfile(). Finally, control
shall be terminated with the consequences described
below.

The _Exit() and _exit() functions shall be functionally
equivalent.

The _Exit() and _exit() functions shall not call
functions registered with atexit() nor any registered signal
handlers. Whether open streams are flushed or closed, or
temporary files are removed is implementa- tion-defined.
Finally, the calling process is terminated with the con-
sequences described below.

These functions shall terminate the calling process with
the following consequences:

Note: These consequences are all extensions to the ISO C
standard and are not further CX shaded. However, XSI
extensions are shaded.

* All of the file descriptors, directory streams,
conversion descrip- tors, and message catalog descriptors
open in the calling process shall be closed.

* If the parent process of the calling process is
executing a wait() or waitpid(), and has neither set its
SA_NOCLDWAIT flag nor set SIGCHLD to SIG_IGN, it shall be
notified of the calling process termination and the
low-order eight bits (that is, bits 0377) of status shall be
made available to it. If the parent is not waiting, the
child s status shall be made available to it when the parent
subsequently executes wait() or waitpid().

The semantics of the waitid() function shall be
equivalent to wait().

* If the parent process of the calling process is not
executing a wait() or waitpid(), and has neither set its
SA_NOCLDWAIT flag nor set SIGCHLD to SIG_IGN, the calling
process shall be transformed into a zombie process. A zombie
process is an inactive process and it shall be deleted at
some later time when its parent process exe- cutes wait() or
waitpid().

The semantics of the waitid() function shall be
equivalent to wait().

* Termination of a process does not directly terminate
its children. The sending of a SIGHUP signal as described
below indirectly termi- nates children in some
circumstances.

* Either:

If the implementation supports the SIGCHLD signal, a
SIGCHLD shall be sent to the parent process.

Or:

If the parent process has set its SA_NOCLDWAIT flag, or
set SIGCHLD to SIG_IGN, the status shall be discarded, and
the lifetime of the calling process shall end immediately.
If SA_NOCLDWAIT is set, it is implemen- tation-defined
whether a SIGCHLD signal is sent to the parent process.

* The parent process ID of all of the calling process
existing child processes and zombie processes shall be set
to the process ID of an implementation-defined system
process. That is, these processes shall be inherited by a
special system process.

* Each attached shared-memory segment is detached and
the value of shm_nattch (see shmget()) in the data structure
associated with its shared memory ID shall be decremented by
1.

* For each semaphore for which the calling process has
set a semadj value (see semop()), that value shall be added
to the semval of the specified semaphore.

* If the process is a controlling process, the SIGHUP
signal shall be sent to each process in the foreground
process group of the control- ling terminal belonging to the
calling process.

* If the process is a controlling process, the
controlling terminal associated with the session shall be
disassociated from the session, allowing it to be acquired
by a new controlling process.

* If the exit of the process causes a process group to
become orphaned, and if any member of the newly-orphaned
process group is stopped, then a SIGHUP signal followed by a
SIGCONT signal shall be sent to each process in the
newly-orphaned process group.

* All open named semaphores in the calling process shall
be closed as if by appropriate calls to sem_close().

* Any memory locks established by the process via calls
to mlockall() or mlock() shall be removed. If locked pages
in the address space of the calling process are also mapped
into the address spaces of other processes and are locked by
those processes, the locks established by the other
processes shall be unaffected by the call by this pro- cess
to _Exit() or _exit().

* Memory mappings that were created in the process shall
be unmapped before the process is destroyed.

* Any blocks of typed memory that were mapped in the
calling process shall be unmapped, as if munmap() was
implicitly called to unmap them.

* All open message queue descriptors in the calling
process shall be closed as if by appropriate calls to
mq_close().

* Any outstanding cancelable asynchronous I/O operations
may be can- celed. Those asynchronous I/O operations that
are not canceled shall complete as if the _Exit() or _exit()
operation had not yet occurred, but any associated signal
notifications shall be sup- pressed. The _Exit() or _exit()
operation may block awaiting such I/O completion. Whether
any I/O is canceled, and which I/O may be canceled upon
_Exit() or _exit(), is implementation-defined.

* Threads terminated by a call to _Exit() or _exit()
shall not invoke their cancellation cleanup handlers or
per-thread data destructors.

* If the calling process is a trace controller process,
any trace streams that were created by the calling process
shall be shut down as described by the
posix_trace_shutdown() function, and any pro- cess mapping
of trace event names to trace event type identifiers built
for these trace streams may be deallocated.

RETURN VALUE These functions do not return.

ERRORS No errors are defined.

The following sections are informative.

EXAMPLES None.

APPLICATION USAGE Normally applications should use
exit() rather than _Exit() or _exit().

RATIONALE Process Termination Early proposals drew a
distinction between normal and abnormal process termination.
Abnormal termination was caused only by certain signals and
resulted in implementation-defined "actions", as
discussed below. Subsequent proposals distinguished three
types of termination: normal termination (as in the current
specification), simple abnormal termina- tion, and abnormal
termination with actions. Again the distinction between the
two types of abnormal termination was that they were caused
by different signals and that implementation-defined actions
would result in the latter case. Given that these actions
were completely implementation-defined, the early proposals
were only saying when the actions could occur and how their
occurrence could be detected, but not what they were. This
was of little or no use to conforming applica- tions, and
thus the distinction is not made in this volume of IEEE Std
1003.1-2001.

The implementation-defined actions usually include, in
most historical implementations, the creation of a file
named core in the current work- ing directory of the
process. This file contains an image of the memory of the
process, together with descriptive information about the
pro- cess, perhaps sufficient to reconstruct the state of
the process at the receipt of the signal.

There is a potential security problem in creating a core
file if the process was set-user-ID and the current user is
not the owner of the program, if the process was
set-group-ID and none of the users groups match the group of
the program, or if the user does not have permission to
write in the current directory. In this situation, an
implementation either should not create a core file or
should make it unreadable by the user.

Despite the silence of this volume of IEEE Std
1003.1-2001 on this fea- ture, applications are advised not
to create files named core because of potential conflicts in
many implementations. Some implementations use a name other
than core for the file; for example, by appending the
process ID to the filename.

Terminating a Process It is important that the
consequences of process termination as described occur
regardless of whether the process called _exit() (per- haps
indirectly through exit()) or instead was terminated due to
a sig- nal or for some other reason. Note that in the
specific case of exit() this means that the status argument
to exit() is treated in the same way as the status argument
to _exit().

A language other than C may have other termination
primitives than the C-language exit() function, and programs
written in such a language should use its native termination
primitives, but those should have as part of their function
the behavior of _exit() as described. Implemen- tations in
languages other than C are outside the scope of this version
of this volume of IEEE Std 1003.1-2001, however.

As required by the ISO C standard, using return from
main() has the same behavior (other than with respect to
language scope issues) as calling exit() with the returned
value. Reaching the end of the main() function has the same
behavior as calling exit(0).

A value of zero (or EXIT_SUCCESS, which is required to
be zero) for the argument status conventionally indicates
successful termination. This corresponds to the
specification for exit() in the ISO C standard. The
convention is followed by utilities such as make and various
shells, which interpret a zero status from a child process
as success. For this reason, applications should not call
exit(0) or _exit(0) when they terminate unsuccessfully; for
example, in signal-catching functions.

Historically, the implementation-defined process that
inherits children whose parents have terminated without
waiting on them is called init and has a process ID of
1.

The sending of a SIGHUP to the foreground process group
when a control- ling process terminates corresponds to
somewhat different historical implementations. In System V,
the kernel sends a SIGHUP on termination of (essentially) a
controlling process. In 4.2 BSD, the kernel does not send
SIGHUP in a case like this, but the termination of a
controlling process is usually noticed by a system daemon,
which arranges to send a SIGHUP to the foreground process
group with the vhangup() function. However, in 4.2 BSD, due
to the behavior of the shells that support job control, the
controlling process is usually a shell with no other pro-
cesses in its process group. Thus, a change to make _exit()
behave this way in such systems should not cause problems
with existing applica- tions.

The termination of a process may cause a process group
to become orphaned in either of two ways. The connection of
a process group to its parent(s) outside of the group
depends on both the parents and their children. Thus, a
process group may be orphaned by the termina- tion of the
last connecting parent process outside of the group or by
the termination of the last direct descendant of the parent
pro- cess(es). In either case, if the termination of a
process causes a pro- cess group to become orphaned,
processes within the group are discon- nected from their job
control shell, which no longer has any informa- tion on the
existence of the process group. Stopped processes within the
group would languish forever. In order to avoid this
problem, newly orphaned process groups that contain stopped
processes are sent a SIGHUP signal and a SIGCONT signal to
indicate that they have been dis- connected from their
session. The SIGHUP signal causes the process group members
to terminate unless they are catching or ignoring SIGHUP.
Under most circumstances, all of the members of the process
group are stopped if any of them are stopped.

The action of sending a SIGHUP and a SIGCONT signal to
members of a newly orphaned process group is similar to the
action of 4.2 BSD, which sends SIGHUP and SIGCONT to each
stopped child of an exiting process. If such children exit
in response to the SIGHUP, any additional descen- dants
receive similar treatment at that time. In this volume of
IEEE Std 1003.1-2001, the signals are sent to the entire
process group at the same time. Also, in this volume of IEEE
Std 1003.1-2001, but not in 4.2 BSD, stopped processes may
be orphaned, but may be members of a process group that is
not orphaned; therefore, the action taken at _exit() must
consider processes other than child processes.

It is possible for a process group to be orphaned by a
call to setpgid() or setsid(), as well as by process
termination. This volume of IEEE Std 1003.1-2001 does not
require sending SIGHUP and SIGCONT in those cases, because,
unlike process termination, those cases are not caused
accidentally by applications that are unaware of job
control. An implementation can choose to send SIGHUP and
SIGCONT in those cases as an extension; such an extension
must be documented as required in <sig- nal.h>.

The ISO/IEC 9899:1999 standard adds the _Exit() function
that results in immediate program termination without
triggering signals or atexit()-registered functions. In IEEE
Std 1003.1-2001, this is equiva- lent to the _exit()
function.

COPYRIGHT Portions of this text are reprinted and
reproduced in electronic form from IEEE Std 1003.1, 2003
Edition, Standard for Information Technology -- Portable
Operating System Interface (POSIX), The Open Group Base
Specifications Issue 6, Copyright (C) 2001-2003 by the
Institute of Electrical and Electronics Engineers, Inc and
The Open Group. In the event of any discrepancy between this
version and the original IEEE and The Open Group Standard,
the original IEEE and The Open Group Standard is the referee
document. The original Standard can be obtained online at
http://www.opengroup.org/unix/online.html .