2004-11-03 13:51:07 +00:00
|
|
|
.\" Copyright (c) 2001-2003 The Open Group, All Rights Reserved
|
2007-06-20 22:33:04 +00:00
|
|
|
.TH "EXIT" 3P 2003 "IEEE/The Open Group" "POSIX Programmer's Manual"
|
2004-11-03 13:51:07 +00:00
|
|
|
.\" exit
|
2007-09-20 06:03:25 +00:00
|
|
|
.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.
|
2004-11-03 13:51:07 +00:00
|
|
|
.SH NAME
|
|
|
|
exit, _Exit, _exit \- terminate a process
|
|
|
|
.SH SYNOPSIS
|
|
|
|
.LP
|
|
|
|
\fB#include <stdlib.h>
|
|
|
|
.br
|
|
|
|
.sp
|
|
|
|
void exit(int\fP \fIstatus\fP\fB);
|
|
|
|
.br
|
|
|
|
void _Exit(int\fP \fIstatus\fP\fB);
|
|
|
|
.br
|
|
|
|
.sp
|
|
|
|
.sp
|
|
|
|
#include <unistd.h>
|
|
|
|
.br
|
|
|
|
void _exit(int\fP \fIstatus\fP\fB);
|
|
|
|
.br
|
|
|
|
\fP
|
|
|
|
.SH DESCRIPTION
|
|
|
|
.LP
|
|
|
|
For \fIexit\fP() and \fI_Exit\fP(): 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.
|
|
|
|
.LP
|
|
|
|
The value of \fIstatus\fP may be 0, EXIT_SUCCESS, EXIT_FAILURE,
|
|
|
|
\ or any other value, though only the least significant 8 bits
|
|
|
|
(that is, \fIstatus\fP & 0377) shall be available to a waiting parent
|
|
|
|
process.
|
|
|
|
.LP
|
|
|
|
The \fIexit\fP() function shall first call all functions registered
|
|
|
|
by \fIatexit\fP(),
|
|
|
|
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 \fIlongjmp\fP() function is made
|
|
|
|
that would terminate
|
|
|
|
the call to the registered function, the behavior is undefined.
|
|
|
|
.LP
|
|
|
|
If a function registered by a call to \fIatexit\fP() fails to return,
|
|
|
|
the remaining
|
|
|
|
registered functions shall not be called and the rest of the \fIexit\fP()
|
|
|
|
processing shall not be completed. If \fIexit\fP() is
|
|
|
|
called more than once, the behavior is undefined.
|
|
|
|
.LP
|
|
|
|
The \fIexit\fP() function shall then flush all open streams with unwritten
|
|
|
|
buffered data, close all open streams, and remove
|
|
|
|
all files created by \fItmpfile\fP(). Finally, control shall be terminated
|
|
|
|
with the
|
|
|
|
consequences described below.
|
|
|
|
.LP
|
|
|
|
The
|
|
|
|
\fI_Exit\fP() and \fI_exit\fP() functions shall be functionally equivalent.
|
|
|
|
.LP
|
2007-11-18 06:52:48 +00:00
|
|
|
The \fI_Exit\fP() and \fI_exit\fP() functions
|
2004-11-03 13:51:07 +00:00
|
|
|
shall not call functions registered with \fIatexit\fP() nor any registered
|
|
|
|
signal handlers.
|
|
|
|
Whether open streams are flushed or closed, or temporary files are
|
|
|
|
removed is implementation-defined. Finally, the calling process
|
|
|
|
is terminated with the consequences described below.
|
|
|
|
.LP
|
2007-11-18 06:52:48 +00:00
|
|
|
These functions shall terminate the calling process with the following
|
2004-11-03 13:51:07 +00:00
|
|
|
consequences:
|
|
|
|
.TP 7
|
|
|
|
\fBNote:\fP
|
|
|
|
These consequences are all extensions to the ISO\ C standard and are
|
|
|
|
not further CX shaded. However, XSI extensions are
|
|
|
|
shaded.
|
|
|
|
.sp
|
|
|
|
.IP " *" 3
|
2007-11-18 06:52:48 +00:00
|
|
|
All of the file descriptors, directory streams, conversion descriptors,
|
|
|
|
and message catalog descriptors open in the calling process shall
|
2004-11-03 13:51:07 +00:00
|
|
|
be closed.
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
If the parent process of the calling process is executing a \fIwait\fP()
|
2007-11-18 06:52:48 +00:00
|
|
|
or \fIwaitpid\fP(), and has neither set its SA_NOCLDWAIT flag
|
2004-11-03 13:51:07 +00:00
|
|
|
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 \fIstatus\fP
|
|
|
|
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 \fIwait\fP() or \fIwaitpid\fP().
|
|
|
|
.LP
|
|
|
|
The semantics of the \fIwaitid\fP() function shall be equivalent to
|
|
|
|
\fIwait\fP().
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
If the parent process of the calling process is not executing a \fIwait\fP()
|
2007-11-18 06:52:48 +00:00
|
|
|
or \fIwaitpid\fP(), and has neither set its SA_NOCLDWAIT flag
|
2004-11-03 13:51:07 +00:00
|
|
|
nor set SIGCHLD to
|
|
|
|
SIG_IGN, the calling process shall be transformed into a \fIzombie
|
|
|
|
process\fP. A \fIzombie process\fP is an inactive process and it shall
|
|
|
|
be deleted at some later time when its parent process
|
|
|
|
executes \fIwait\fP() or \fIwaitpid\fP().
|
|
|
|
.LP
|
|
|
|
The semantics of the \fIwaitid\fP() function shall be equivalent to
|
|
|
|
\fIwait\fP().
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
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.
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
Either:
|
|
|
|
.LP
|
|
|
|
If the implementation supports the SIGCHLD signal, a SIGCHLD shall
|
|
|
|
be sent to the parent process.
|
|
|
|
.LP
|
|
|
|
Or:
|
|
|
|
.LP
|
|
|
|
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 implementation-defined whether a SIGCHLD signal is sent to
|
|
|
|
the parent process.
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
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.
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
Each attached shared-memory segment is detached and the value of \fIshm_nattch\fP
|
|
|
|
(see \fIshmget\fP()) in the data structure associated with its shared
|
|
|
|
memory ID shall be decremented by
|
|
|
|
1.
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
For each semaphore for which the calling process has set a \fIsemadj\fP
|
2007-11-18 06:26:46 +00:00
|
|
|
value (see \fIsemop\fP()), that
|
2004-11-03 13:51:07 +00:00
|
|
|
value shall be added to the \fIsemval\fP of the specified semaphore.
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
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.
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
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.
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
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.
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
All open named semaphores in the calling process shall be closed as
|
|
|
|
if by appropriate calls to \fIsem_close\fP().
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
Any
|
|
|
|
memory locks established by the process via calls to \fImlockall\fP()
|
|
|
|
or \fImlock\fP() 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\fP() or
|
|
|
|
\fI_exit\fP().
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
Memory mappings that were created in the process shall be unmapped
|
|
|
|
before the process is destroyed.
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
Any blocks of typed memory that were mapped in the calling process
|
|
|
|
shall be unmapped, as if \fImunmap\fP() was implicitly called to unmap
|
|
|
|
them.
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
All open message queue descriptors in the calling process shall be
|
|
|
|
closed as if by appropriate calls to \fImq_close\fP().
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
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\fP() or \fI_exit\fP() operation
|
|
|
|
had not yet occurred, but any associated signal notifications
|
|
|
|
shall be suppressed. The \fI_Exit\fP() or \fI_exit\fP() operation
|
|
|
|
may block awaiting such I/O completion. Whether any I/O is
|
|
|
|
canceled, and which I/O may be canceled upon \fI_Exit\fP() or \fI_exit\fP(),
|
|
|
|
is implementation-defined.
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
Threads terminated by a call to \fI_Exit\fP() or \fI_exit\fP() shall
|
|
|
|
not invoke their cancellation cleanup handlers or
|
|
|
|
per-thread data destructors.
|
|
|
|
.LP
|
|
|
|
.IP " *" 3
|
|
|
|
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\fP() function, and any
|
|
|
|
process'
|
|
|
|
mapping of trace event names to trace event type identifiers built
|
|
|
|
for these trace streams may be deallocated.
|
|
|
|
.LP
|
|
|
|
.SH RETURN VALUE
|
|
|
|
.LP
|
|
|
|
These functions do not return.
|
|
|
|
.SH ERRORS
|
|
|
|
.LP
|
|
|
|
No errors are defined.
|
|
|
|
.LP
|
|
|
|
\fIThe following sections are informative.\fP
|
|
|
|
.SH EXAMPLES
|
|
|
|
.LP
|
|
|
|
None.
|
|
|
|
.SH APPLICATION USAGE
|
|
|
|
.LP
|
|
|
|
Normally applications should use \fIexit\fP() rather than \fI_Exit\fP()
|
|
|
|
or \fI_exit\fP().
|
|
|
|
.SH RATIONALE
|
|
|
|
.SS Process Termination
|
|
|
|
.LP
|
|
|
|
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 IEEE\ Std\ 1003.1-2001.
|
|
|
|
.LP
|
|
|
|
The implementation-defined actions usually include, in most historical
|
|
|
|
implementations, the creation of a file named \fBcore\fP
|
|
|
|
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.
|
|
|
|
.LP
|
|
|
|
There is a potential security problem in creating a \fBcore\fP 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
|
|
|
|
\fBcore\fP file or should make it unreadable by the user.
|
|
|
|
.LP
|
|
|
|
Despite the silence of this volume of IEEE\ Std\ 1003.1-2001 on this
|
|
|
|
feature, applications are advised not to create
|
|
|
|
files named \fBcore\fP because of potential conflicts in many implementations.
|
|
|
|
Some implementations use a name other than
|
|
|
|
\fBcore\fP for the file; for example, by appending the process ID
|
|
|
|
to the filename.
|
|
|
|
.SS Terminating a Process
|
|
|
|
.LP
|
|
|
|
It is important that the consequences of process termination as described
|
|
|
|
occur regardless of whether the process called
|
|
|
|
\fI_exit\fP() (perhaps indirectly through \fIexit\fP()) or instead
|
|
|
|
was terminated due to a signal or for some other reason. Note
|
|
|
|
that in the specific case of \fIexit\fP() this means that the \fIstatus\fP
|
|
|
|
argument to \fIexit\fP() is treated in the same way
|
|
|
|
as the \fIstatus\fP argument to \fI_exit\fP().
|
|
|
|
.LP
|
|
|
|
A language other than C may have other termination primitives than
|
|
|
|
the C-language \fIexit\fP() 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\fP() as described. Implementations in languages other than
|
|
|
|
C are outside the scope of this version of this volume of
|
|
|
|
IEEE\ Std\ 1003.1-2001, however.
|
|
|
|
.LP
|
|
|
|
As required by the ISO\ C standard, using \fBreturn\fP from \fImain\fP()
|
|
|
|
has the same behavior (other than with respect to
|
|
|
|
language scope issues) as calling \fIexit\fP() with the returned value.
|
|
|
|
Reaching the end of the \fImain\fP() function has the
|
|
|
|
same behavior as calling \fIexit\fP(0).
|
|
|
|
.LP
|
|
|
|
A value of zero (or EXIT_SUCCESS, which is required to be zero) for
|
|
|
|
the argument \fIstatus\fP conventionally indicates
|
|
|
|
successful termination. This corresponds to the specification for
|
|
|
|
\fIexit\fP() in the ISO\ C standard. The convention is
|
|
|
|
followed by utilities such as \fImake\fP 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.
|
|
|
|
.LP
|
|
|
|
Historically, the implementation-defined process that inherits children
|
|
|
|
whose parents have terminated without waiting on them is
|
|
|
|
called \fIinit\fP and has a process ID of 1.
|
|
|
|
.LP
|
|
|
|
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\fP() 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\fP() behave
|
|
|
|
this way in such systems should not cause problems with existing
|
|
|
|
applications.
|
|
|
|
.LP
|
|
|
|
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.
|
|
|
|
.LP
|
|
|
|
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 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
|
|
|
|
\fI_exit\fP() must consider processes other than child processes.
|
|
|
|
.LP
|
|
|
|
It is possible for a process group to be orphaned by a call to \fIsetpgid\fP()
|
|
|
|
or \fIsetsid\fP(), 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 \fI<signal.h>\fP.
|
|
|
|
.LP
|
|
|
|
The ISO/IEC\ 9899:1999 standard adds the \fI_Exit\fP() function that
|
|
|
|
results in immediate program termination without
|
|
|
|
triggering signals or \fIatexit\fP()-registered functions. In
|
|
|
|
IEEE\ Std\ 1003.1-2001, this is equivalent to the \fI_exit\fP() function.
|
|
|
|
.SH FUTURE DIRECTIONS
|
|
|
|
.LP
|
|
|
|
None.
|
|
|
|
.SH SEE ALSO
|
|
|
|
.LP
|
2007-09-20 17:56:19 +00:00
|
|
|
\fIatexit\fP(), \fIclose\fP(), \fIfclose\fP(),
|
|
|
|
\fIlongjmp\fP(), \fIposix_trace_shutdown\fP(), \fIposix_trace_trid_eventid_open\fP(),
|
|
|
|
\fIsemop\fP(), \fIshmget\fP(), \fIsigaction\fP(), \fIwait\fP()
|
2004-11-03 13:51:07 +00:00
|
|
|
,
|
2007-09-20 06:11:55 +00:00
|
|
|
\fIwaitid\fP(), \fIwaitpid\fP(), the Base Definitions volume of
|
2004-11-03 13:51:07 +00:00
|
|
|
IEEE\ Std\ 1003.1-2001, \fI<stdlib.h>\fP, \fI<unistd.h>\fP
|
|
|
|
.SH 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 .
|