_EXIT(3POSIX) POSIX Programmer's Manual _EXIT(3POSIX)
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.
_Exit, _exit — terminate a process
void _Exit(int status);
void _exit(int status);
For _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 POSIX.1‐2008 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 par‐
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. Open streams shall not be flushed. Whether open streams
are closed (without flushing) is implementation-defined. Finally, the calling process
shall be terminated with the consequences described below.
Consequences of Process Termination
Process termination caused by any reason shall have the following consequences:
Note: These consequences are all extensions to the ISO C standard and are not further
CX shaded. However, functionality relating to the XSI option is shaded.
* All of the file descriptors, directory streams, conversion descriptors, and message
catalog descriptors open in the calling process shall be closed.
* If the parent process of the calling process is executing a wait(), waitid(), or wait‐
pid(), and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to SIG_IGN, it shall
be notified of termination of the calling process 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(), waitid(), 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(), waitid(), 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
executes wait(), waitid(), 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 terminates children in some circumstances.
If the implementation supports the SIGCHLD signal, a SIGCHLD shall be sent to the par‐
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 immedi‐
ately. If SA_NOCLDWAIT is set, it is implementation-defined whether a SIGCHLD signal
is sent to the parent process.
* The parent process ID of all of the existing child processes and zombie processes of
the calling process 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 decre‐
mented 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 controlling terminal belonging to the
* 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
* If the exit of the process causes a process group to become orphaned, and if any mem‐
ber 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
process to _Exit() or _exit().
* Memory mappings that were created in the process shall be unmapped before the process
* 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 canceled. Those asyn‐
chronous 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 suppressed. The _Exit() or _exit() operation may block awaiting such I/O comple‐
tion. 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 cre‐
ated by the calling process shall be shut down as described by the posix_trace_shut‐
down() function, and mapping of trace event names to trace event type identifiers of
any process built for these trace streams may be deallocated.
These functions do not return.
No errors are defined.
The following sections are informative.
Normally applications should use exit() rather than _Exit() or _exit().
Early proposals drew a distinction between normal and abnormal process termination. Abnor‐
mal termination was caused only by certain signals and resulted in implementation-defined
``actions'', as discussed below. Subsequent proposals distinguished three types of termi‐
nation: normal termination (as in the current specification), simple abnormal termination,
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 implementa‐
tion-defined actions would result in the latter case. Given that these actions were com‐
pletely 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 applications, and thus the distinction is not made in
this volume of POSIX.1‐2008.
The implementation-defined actions usually include, in most historical implementations,
the creation of a file named core in the current working directory of the process. This
file contains an image of the memory of the process, together with descriptive information
about the process, 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 user's 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 POSIX.1‐2008 on this feature, applications are
advised not to create files named core because of potential conflicts in many implementa‐
tions. 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() (perhaps indirectly through exit()) or instead was
terminated due to a signal 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 primi‐
tives, but those should have as part of their function the behavior of _exit() as
described. Implementations in languages other than C are outside the scope of this version
of this volume of POSIX.1‐2008, 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 unsuccess‐
fully; 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 controlling process termi‐
nates corresponds to somewhat different historical implementations. In System V, the ker‐
nel 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 processes in its process group. Thus, a change to make _exit() behave
this way in such systems should not cause problems with existing applications.
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 process(es). In either case, if the termination
of a process causes a process group to become orphaned, processes within the group are
disconnected from their job control shell, which no longer has any information 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 pro‐
cesses 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 ter‐
minate 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 addi‐
tional descendants receive similar treatment at that time. In this volume of POSIX.1‐2008,
the signals are sent to the entire process group at the same time. Also, in this volume of
POSIX.1‐2008, 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 POSIX.1‐2008 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 <signal.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 POSIX.1‐2008,
this is equivalent to the _exit() function.
atexit(), exit(), mlock(), mlockall(), mq_close(), munmap(), posix_trace_create(),
sem_close(), semop(), setpgid(), setsid(), shmget(), wait(), waitid()
The Base Definitions volume of POSIX.1‐2008, <stdlib.h>, <unistd.h>
Portions of this text are reprinted and reproduced in electronic form from IEEE Std
1003.1, 2013 Edition, Standard for Information Technology -- Portable Operating System
Interface (POSIX), The Open Group Base Specifications Issue 7, Copyright (C) 2013 by the
Institute of Electrical and Electronics Engineers, Inc and The Open Group. (This is
POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the event of any discrep‐
ancy 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.unix.org/online.html .
Any typographical or formatting errors that appear in this page are most likely to have
been introduced during the conversion of the source files to man page format. To report
such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .
IEEE/The Open Group 2013 _EXIT(3POSIX)