# _Exit

## 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 — terminate a process
    


## SYNOPSIS



           #include <stdlib.h>
    
           void _Exit(int _status_);
    
           #include <unistd.h>
    
           void _exit(int _status_);
    


## DESCRIPTION



           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‐2017 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 from _wait_() and _waitpid_(); the
           full value shall be available from _waitid_() and in the **siginfo_t**
           passed to a signal handler for SIGCHLD.
    
           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 has set its
               SA_NOCLDWAIT flag or has set the action for the SIGCHLD signal
               to SIG_IGN:
    
               --  The process' status information (see _Section 2.13_ , _Status_
                   _Information_), if any, shall be discarded.
    
               --  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.
    
               --  If a thread in the parent process of the calling process
                   is blocked in _wait_(), _waitpid_(), or _waitid_(), and the
                   parent process has no remaining child processes in the set
                   of waited-for children, the _wait_(), _waitid_(), or _waitpid_()
                   function shall fail and set _errno_ to **[ECHILD]**.
    
               Otherwise:
    
               --  Status information (see _Section 2.13_ , _Status Information_)
                   shall be generated.
    
               --  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.
    
               --  The process' lifetime shall end once its parent obtains
                   the process' status information via a currently-blocked or
                   future call to _wait_(), _waitid_() (without WNOWAIT), or
                   _waitpid_().
    
               --  If one or more threads in the parent process of the
                   calling process is blocked in a call to _wait_(), _waitid_(),
                   or _waitpid_() awaiting termination of the process, one (or,
                   if any are calling _waitid_() with WNOWAIT, possibly more)
                   of these threads shall obtain the process' status
                   information as specified in _Section 2.13_ , _Status_
                   _Information_ and become unblocked.
    
               --  A SIGCHLD shall be sent to the parent process.
    
            *  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.
    
            *  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 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 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 _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 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
               canceled. 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 suppressed. 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 mapping of trace event names to trace event type
               identifiers of any process 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 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 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‐2017.
    
           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‐2017 on this
           feature, 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_()
           (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 primitives, 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‐2017, 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
           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 _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
           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‐2017, the signals are sent to the entire
           process group at the same time. Also, in this volume of
           POSIX.1‐2017, 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‐2017 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.
    


## FUTURE DIRECTIONS



           None.
    


* * *