oasis-root

_Exit.3p (16148B)

'\" et
.TH _EXIT "3P" 2017 "IEEE/The Open Group" "POSIX Programmer's Manual"
.\"
.SH 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.
.\"
.SH NAME
_Exit,
_exit
\(em terminate a process
.SH SYNOPSIS
.LP
.nf
#include <stdlib.h>
.P
void _Exit(int \fIstatus\fP);
.P
#include <unistd.h>
.P
void _exit(int \fIstatus\fP);
.fi
.SH DESCRIPTION
For
\fI_Exit\fR():
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\(hy2017 defers to the ISO\ C standard.
.P
The value of
.IR status
may be 0, EXIT_SUCCESS, EXIT_FAILURE,
or any other value, though only the least significant 8 bits (that is,
.IR status
& 0377) shall be available from
\fIwait\fR()
and
\fIwaitpid\fR();
the full value shall be available from
\fIwaitid\fR()
and in the
.BR siginfo_t
passed to a signal handler for SIGCHLD.
.P
The
\fI_Exit\fR()
and
\fI_exit\fR()
functions shall be functionally equivalent.
.P
The
\fI_Exit\fR()
and
\fI_exit\fR()
functions shall not call functions registered with
\fIatexit\fR()
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.
.SS "Consequences of Process Termination"
.P
Process termination caused by any reason shall have the following
consequences:
.TP 10
.BR 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.
.P
.IP " *" 4
All of the file descriptors, directory streams, conversion descriptors,
and message catalog descriptors open in the calling process shall
be closed.
.IP " *" 4
If the parent process of the calling process has set its SA_NOCLDWAIT
flag or has set the action for the SIGCHLD signal to SIG_IGN:
.RS 4 
.IP -- 4
The process' status information (see
.IR "Section 2.13" ", " "Status Information"),
if any, shall be discarded.
.IP -- 4
The lifetime of the calling process shall end immediately. If
SA_NOCLDWAIT is set, it is implementation-defined whether a SIGCHLD
signal is sent to the parent process.
.IP -- 4
If a thread in the parent process of the calling process is blocked in
\fIwait\fR(),
\fIwaitpid\fR(),
or
\fIwaitid\fR(),
and the parent process has no remaining child processes in the
set of waited-for children, the
\fIwait\fR(),
\fIwaitid\fR(),
or
\fIwaitpid\fR()
function shall fail and set
.IR errno
to
.BR [ECHILD] .
.P
Otherwise:
.IP -- 4
Status information (see
.IR "Section 2.13" ", " "Status Information")
shall be generated.
.IP -- 4
The calling process shall be transformed into a zombie process. Its
status information shall be made available to the parent process
until the process' lifetime ends.
.IP -- 4
The process' lifetime shall end once its parent obtains the process'
status information via a currently-blocked or future call to
\fIwait\fR(),
\fIwaitid\fR()
(without WNOWAIT), or
\fIwaitpid\fR().
.IP -- 4
If one or more threads in the parent process of the calling process is
blocked in a call to
\fIwait\fR(),
\fIwaitid\fR(),
or
\fIwaitpid\fR()
awaiting termination of the process, one (or, if any are calling
\fIwaitid\fR()
with WNOWAIT, possibly more) of these threads shall obtain the
process' status information as specified in
.IR "Section 2.13" ", " "Status Information"
and become unblocked.
.IP -- 4
A SIGCHLD shall be sent to the parent process.
.RE
.IP " *" 4
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.
.IP " *" 4
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.
.IP " *" 4
Each attached shared-memory segment is detached and the value of
.IR shm_nattch
(see
\fIshmget\fR())
in the data structure associated with its shared memory ID
shall be decremented by 1.
.IP " *" 4
For each semaphore for which the calling process has set a
.IR semadj
value (see
\fIsemop\fR()),
that value shall be added to the
.IR semval
of the specified semaphore.
.IP " *" 4
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 calling process.
.IP " *" 4
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.
.IP " *" 4
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.
.IP " *" 4
All open named semaphores in the calling process shall be closed as
if by appropriate calls to
\fIsem_close\fR().
.IP " *" 4
Any memory locks established by the process via calls to
\fImlockall\fR()
or
\fImlock\fR()
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
\fI_Exit\fR()
or
\fI_exit\fR().
.IP " *" 4
Memory mappings that were created in the process shall be unmapped
before the process is destroyed.
.IP " *" 4
Any blocks of typed memory that were mapped in the calling process
shall be unmapped, as if
\fImunmap\fR()
was implicitly called to unmap them.
.IP " *" 4
All open message queue descriptors in the calling process shall be
closed as if by appropriate calls to
\fImq_close\fR().
.IP " *" 4
Any outstanding cancelable asynchronous I/O operations may be
canceled. Those asynchronous I/O operations that are not canceled
shall complete as if the
\fI_Exit\fR()
or
\fI_exit\fR()
operation had not yet occurred, but any associated signal notifications
shall be suppressed. The
\fI_Exit\fR()
or
\fI_exit\fR()
operation may block awaiting such I/O completion. Whether any
I/O is canceled, and which I/O may be canceled upon
\fI_Exit\fR()
or
\fI_exit\fR(),
is implementation-defined.
.IP " *" 4
Threads terminated by a call to
\fI_Exit\fR()
or
\fI_exit\fR()
shall not invoke their cancellation cleanup handlers or per-thread data
destructors.
.IP " *" 4
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
\fIposix_trace_shutdown\fR()
function, and mapping of trace event names to trace event type identifiers
of any process built for these trace streams may be deallocated.
.SH "RETURN VALUE"
These functions do not return.
.SH ERRORS
No errors are defined.
.LP
.IR "The following sections are informative."
.SH EXAMPLES
None.
.SH "APPLICATION USAGE"
Normally applications should use
\fIexit\fR()
rather than
\fI_Exit\fR()
or
\fI_exit\fR().
.SH RATIONALE
.SS "Process Termination"
.P
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:
\fInormal termination\fP (as in the current specification), \fIsimple
abnormal termination\fP, and \fIabnormal termination with actions\fP.
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 applications, and thus the distinction is
not made in this volume of POSIX.1\(hy2017.
.P
The implementation-defined actions usually include, in most
historical implementations, the creation of a file named
.BR 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.
.P
There is a potential security problem in creating a
.BR 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
.BR core
file or should make it unreadable by the user.
.P
Despite the silence of this volume of POSIX.1\(hy2017 on this feature, applications are
advised not to create files named
.BR core
because of potential conflicts in many implementations. Some
implementations use a name other than
.BR core
for the file; for example, by appending the process ID to the filename.
.SS "Terminating a Process"
.P
It is important that the consequences of process termination as
described occur regardless of whether the process called
\fI_exit\fR()
(perhaps indirectly through
\fIexit\fR())
or instead was terminated due to a signal or for some other reason.
Note that in the specific case of
\fIexit\fR()
this means that the
.IR status
argument to
\fIexit\fR()
is treated in the same way as the
.IR status
argument to
\fI_exit\fR().
.P
A language other than C may have other termination primitives than the
C-language
\fIexit\fR()
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
\fI_exit\fR()
as described. Implementations in languages other than C are outside
the scope of this version of this volume of POSIX.1\(hy2017, however.
.P
As required by the ISO\ C standard, using
.BR return
from
\fImain\fR()
has the same behavior (other than with respect to language scope
issues) as calling
\fIexit\fR()
with the returned value. Reaching the end of the
\fImain\fR()
function has the same behavior as calling
.IR exit (0).
.P
A value of zero (or EXIT_SUCCESS, which is required to be zero)
for the argument
.IR status
conventionally indicates successful termination. This corresponds to
the specification for
\fIexit\fR()
in the ISO\ C standard. The convention is followed by utilities such as
.IR make
and various shells, which interpret a zero status
from a child process as success. For this reason, applications should
not call \fIexit\fP(0) or \fI_exit\fP(0) when they terminate
unsuccessfully; for example, in signal-catching functions.
.P
Historically, the implementation-defined process that inherits
children whose parents have terminated without waiting on them is
called
.IR init
and has a process ID of 1.
.P
The sending of a SIGHUP
to the foreground process group when a controlling 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
\fIvhangup\fR()
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
\fI_exit\fR()
behave this way in such systems should not cause problems with existing
applications.
.P
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 termination 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 processes are sent a SIGHUP signal and a SIGCONT
signal to indicate that they have been disconnected 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.
.P
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
descendants receive similar treatment at that time. In this volume of POSIX.1\(hy2017, the
signals are sent to the entire process group at the same time. Also,
in this volume of POSIX.1\(hy2017, 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
\fI_exit\fR()
must consider processes other than child processes.
.P
It is possible for a process group to be orphaned by a call to
\fIsetpgid\fR()
or
\fIsetsid\fR(),
as well as by process termination. This volume of POSIX.1\(hy2017 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
.IR <signal.h> .
.P
The ISO/IEC\ 9899:\|1999 standard adds the
\fI_Exit\fR()
function that results in immediate program termination without
triggering signals or
\fIatexit\fR()-registered
functions. In POSIX.1\(hy2008, this is equivalent to the
\fI_exit\fR()
function.
.SH "FUTURE DIRECTIONS"
None.
.SH "SEE ALSO"
.IR "\fIatexit\fR\^(\|)",
.IR "\fIexit\fR\^(\|)",
.IR "\fImlock\fR\^(\|)",
.IR "\fImlockall\fR\^(\|)",
.IR "\fImq_close\fR\^(\|)",
.IR "\fImunmap\fR\^(\|)",
.IR "\fIposix_trace_create\fR\^(\|)",
.IR "\fIsem_close\fR\^(\|)",
.IR "\fIsemop\fR\^(\|)",
.IR "\fIsetpgid\fR\^(\|)",
.IR "\fIsetsid\fR\^(\|)",
.IR "\fIshmget\fR\^(\|)",
.IR "\fIwait\fR\^(\|)",
.IR "\fIwaitid\fR\^(\|)"
.P
The Base Definitions volume of POSIX.1\(hy2017,
.IR "\fB<stdlib.h>\fP",
.IR "\fB<unistd.h>\fP"
.\"
.SH COPYRIGHT
Portions of this text are reprinted and reproduced in electronic form
from IEEE Std 1003.1-2017, Standard for Information Technology
-- Portable Operating System Interface (POSIX), The Open Group Base
Specifications Issue 7, 2018 Edition,
Copyright (C) 2018 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 .
.PP
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 .