_EXIT(3)                   POSIX Programmer's Manual                  _EXIT(3)



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


NNAAMMEE
       _Exit, _exit -- terminate a process

SSYYNNOOPPSSIISS
       #include <stdlib.h>

       void _Exit(int _s_t_a_t_u_s);

       #include <unistd.h>

       void _exit(int _s_t_a_t_u_s);

DDEESSCCRRIIPPTTIIOONN
       For ___E_x_i_t(): 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 _s_t_a_t_u_s may be 0, EXIT_SUCCESS, EXIT_FAILURE, or any other
       value, though only the least significant 8 bits (that is, _s_t_a_t_u_s &
       0377) shall be available to a waiting parent process.

       The ___E_x_i_t() and ___e_x_i_t() functions shall be functionally equivalent.

       The ___E_x_i_t() and ___e_x_i_t() functions shall not call functions registered
       with _a_t_e_x_i_t() 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.

   CCoonnsseeqquueenncceess ooff PPrroocceessss TTeerrmmiinnaattiioonn
       Process termination caused by any reason shall have the following
       consequences:

       NNoottee::     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 _w_a_i_t(),
           _w_a_i_t_i_d(), or _w_a_i_t_p_i_d(), 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 _s_t_a_t_u_s 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 _w_a_i_t(), _w_a_i_t_i_d(), or _w_a_i_t_p_i_d().

           The semantics of the _w_a_i_t_i_d() function shall be equivalent to
           _w_a_i_t().

        *  If the parent process of the calling process is not executing a
           _w_a_i_t(), _w_a_i_t_i_d(), or _w_a_i_t_p_i_d(), and has neither set its
           SA_NOCLDWAIT flag nor set SIGCHLD to SIG_IGN, the calling process
           shall be transformed into a _z_o_m_b_i_e _p_r_o_c_e_s_s.  A _z_o_m_b_i_e _p_r_o_c_e_s_s is an
           inactive process and it shall be deleted at some later time when
           its parent process executes _w_a_i_t(), _w_a_i_t_i_d(), or _w_a_i_t_p_i_d().

           The semantics of the _w_a_i_t_i_d() function shall be equivalent to
           _w_a_i_t().

        *  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.

        *  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 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
           _s_h_m___n_a_t_t_c_h (see _s_h_m_g_e_t()) 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 _s_e_m_a_d_j
           value (see _s_e_m_o_p()), that value shall be added to the _s_e_m_v_a_l 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 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 _s_e_m___c_l_o_s_e().

        *  Any memory locks established by the process via calls to _m_l_o_c_k_a_l_l()
           or _m_l_o_c_k() 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 ___E_x_i_t() or ___e_x_i_t().

        *  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 _m_u_n_m_a_p() was implicitly called to unmap
           them.

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

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

        *  Threads terminated by a call to ___E_x_i_t() or ___e_x_i_t() 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 _p_o_s_i_x___t_r_a_c_e___s_h_u_t_d_o_w_n() function, and mapping of
           trace event names to trace event type identifiers of any process
           built for these trace streams may be deallocated.

RREETTUURRNN VVAALLUUEE
       These functions do not return.

EERRRROORRSS
       No errors are defined.

       _T_h_e _f_o_l_l_o_w_i_n_g _s_e_c_t_i_o_n_s _a_r_e _i_n_f_o_r_m_a_t_i_v_e_.

EEXXAAMMPPLLEESS
       None.

AAPPPPLLIICCAATTIIOONN UUSSAAGGEE
       Normally applications should use _e_x_i_t() rather than ___E_x_i_t() or ___e_x_i_t().

RRAATTIIOONNAALLEE
   PPrroocceessss TTeerrmmiinnaattiioonn
       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: _n_o_r_m_a_l
       _t_e_r_m_i_n_a_t_i_o_n (as in the current specification), _s_i_m_p_l_e _a_b_n_o_r_m_a_l
       _t_e_r_m_i_n_a_t_i_o_n, and _a_b_n_o_r_m_a_l _t_e_r_m_i_n_a_t_i_o_n _w_i_t_h _a_c_t_i_o_n_s.  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-2008.

       The implementation-defined actions usually include, in most historical
       implementations, the creation of a file named ccoorree 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 ccoorree 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 ccoorree 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 ccoorree because of
       potential conflicts in many implementations. Some implementations use a
       name other than ccoorree for the file; for example, by appending the
       process ID to the filename.

   TTeerrmmiinnaattiinngg aa PPrroocceessss
       It is important that the consequences of process termination as
       described occur regardless of whether the process called ___e_x_i_t()
       (perhaps indirectly through _e_x_i_t()) or instead was terminated due to a
       signal or for some other reason.  Note that in the specific case of
       _e_x_i_t() this means that the _s_t_a_t_u_s argument to _e_x_i_t() is treated in the
       same way as the _s_t_a_t_u_s argument to ___e_x_i_t().

       A language other than C may have other termination primitives than the
       C-language _e_x_i_t() 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 ___e_x_i_t() 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 rreettuurrnn from _m_a_i_n() has the
       same behavior (other than with respect to language scope issues) as
       calling _e_x_i_t() with the returned value. Reaching the end of the _m_a_i_n()
       function has the same behavior as calling _e_x_i_t(0).

       A value of zero (or EXIT_SUCCESS, which is required to be zero) for the
       argument _s_t_a_t_u_s conventionally indicates successful termination. This
       corresponds to the specification for _e_x_i_t() in the ISO C standard. The
       convention is followed by utilities such as _m_a_k_e and various shells,
       which interpret a zero status from a child process as success. For this
       reason, applications should not call _e_x_i_t(0) or ___e_x_i_t(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 _i_n_i_t
       and has a process ID of 1.

       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
       _v_h_a_n_g_u_p() 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 ___e_x_i_t() 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
       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.

       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-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 ___e_x_i_t() must
       consider processes other than child processes.

       It is possible for a process group to be orphaned by a call to
       _s_e_t_p_g_i_d() or _s_e_t_s_i_d(), 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
       _<_s_i_g_n_a_l_._h_>.

       The ISO/IEC 9899:1999 standard adds the ___E_x_i_t() function that results
       in immediate program termination without triggering signals or
       _a_t_e_x_i_t()-registered functions. In POSIX.1-2008, this is equivalent to
       the ___e_x_i_t() function.

FFUUTTUURREE DDIIRREECCTTIIOONNSS
       None.

SSEEEE AALLSSOO
       _a_t_e_x_i_t(), _e_x_i_t(), _m_l_o_c_k(), _m_l_o_c_k_a_l_l(), _m_q___c_l_o_s_e(), _m_u_n_m_a_p(),
       _p_o_s_i_x___t_r_a_c_e___c_r_e_a_t_e(), _s_e_m___c_l_o_s_e(), _s_e_m_o_p(), _s_e_t_p_g_i_d(), _s_e_t_s_i_d(),
       _s_h_m_g_e_t(), _w_a_i_t(), _w_a_i_t_i_d()

       The Base Definitions volume of POSIX.1-2008, <<ssttddlliibb..hh>>, <<uunniissttdd..hh>>

CCOOPPYYRRIIGGHHTT
       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 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.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(3)
