POSIX_SPAWN(3)             POSIX Programmer's Manual            POSIX_SPAWN(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
       posix_spawn, posix_spawnp -- spawn a process (AADDVVAANNCCEEDD RREEAALLTTIIMMEE)

SSYYNNOOPPSSIISS
       #include <spawn.h>

       int posix_spawn(pid_t *restrict _p_i_d, const char *restrict _p_a_t_h,
           const posix_spawn_file_actions_t *_f_i_l_e___a_c_t_i_o_n_s,
           const posix_spawnattr_t *restrict _a_t_t_r_p,
           char *const _a_r_g_v[restrict], char *const _e_n_v_p[restrict]);
       int posix_spawnp(pid_t *restrict _p_i_d, const char *restrict _f_i_l_e,
           const posix_spawn_file_actions_t *_f_i_l_e___a_c_t_i_o_n_s,
           const posix_spawnattr_t *restrict _a_t_t_r_p,
           char *const _a_r_g_v[restrict], char *const _e_n_v_p[restrict]);

DDEESSCCRRIIPPTTIIOONN
       The _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() functions shall create a new
       process (child process) from the specified process image. The new
       process image shall be constructed from a regular executable file
       called the new process image file.

       When a C program is executed as the result of this call, it shall be
       entered as a C-language function call as follows:


           int main(int _a_r_g_c, char *_a_r_g_v[]);

       where _a_r_g_c is the argument count and _a_r_g_v is an array of character
       pointers to the arguments themselves. In addition, the following
       variable:


           extern char **environ;

       shall be initialized as a pointer to an array of character pointers to
       the environment strings.

       The argument _a_r_g_v is an array of character pointers to null-terminated
       strings. The last member of this array shall be a null pointer and is
       not counted in _a_r_g_c.  These strings constitute the argument list
       available to the new process image. The value in _a_r_g_v[0] should point
       to a filename string that is associated with the process image being
       started by the _p_o_s_i_x___s_p_a_w_n() or _p_o_s_i_x___s_p_a_w_n_p() function.

       The argument _e_n_v_p is an array of character pointers to null-terminated
       strings. These strings constitute the environment for the new process
       image. The environment array is terminated by a null pointer.

       The number of bytes available for the combined argument and environment
       lists of the child process is {ARG_MAX}.  The implementation shall
       specify in the system documentation (see the Base Definitions volume of
       POSIX.1-2017, _C_h_a_p_t_e_r _2, _C_o_n_f_o_r_m_a_n_c_e) whether any list overhead, such
       as length words, null terminators, pointers, or alignment bytes, is
       included in this total.

       The _p_a_t_h argument to _p_o_s_i_x___s_p_a_w_n() is a pathname that identifies the
       new process image file to execute.

       The _f_i_l_e parameter to _p_o_s_i_x___s_p_a_w_n_p() shall be used to construct a
       pathname that identifies the new process image file. If the _f_i_l_e
       parameter contains a <slash> character, the _f_i_l_e parameter shall be
       used as the pathname for the new process image file. Otherwise, the
       path prefix for this file shall be obtained by a search of the
       directories passed as the environment variable _P_A_T_H (see the Base
       Definitions volume of POSIX.1-2017, _C_h_a_p_t_e_r _8, _E_n_v_i_r_o_n_m_e_n_t _V_a_r_i_a_b_l_e_s).
       If this environment variable is not defined, the results of the search
       are implementation-defined.

       If _f_i_l_e___a_c_t_i_o_n_s is a null pointer, then file descriptors open in the
       calling process shall remain open in the child process, except for
       those whose close-on-_e_x_e_c flag FD_CLOEXEC is set (see _f_c_n_t_l()).  For
       those file descriptors that remain open, the child process shall not
       inherit any file locks, but all remaining attributes of the
       corresponding open file descriptions (see _f_c_n_t_l()), shall remain
       unchanged.

       If _f_i_l_e___a_c_t_i_o_n_s is not NULL, then the file descriptors open in the
       child process shall be those open in the calling process as modified by
       the spawn file actions object pointed to by _f_i_l_e___a_c_t_i_o_n_s and the
       FD_CLOEXEC flag of each remaining open file descriptor after the spawn
       file actions have been processed. The effective order of processing the
       spawn file actions shall be:

        1. The set of open file descriptors for the child process shall
           initially be the same set as is open for the calling process. The
           child process shall not inherit any file locks, but all remaining
           attributes of the corresponding open file descriptions (see
           _f_c_n_t_l()), shall remain unchanged.

        2. The signal mask, signal default actions, and the effective user and
           group IDs for the child process shall be changed as specified in
           the attributes object referenced by _a_t_t_r_p.

        3. The file actions specified by the spawn file actions object shall
           be performed in the order in which they were added to the spawn
           file actions object.

        4. Any file descriptor that has its FD_CLOEXEC flag set (see _f_c_n_t_l())
           shall be closed.

       If file descriptor 0, 1, or 2 would otherwise be closed in the new
       process image created by _p_o_s_i_x___s_p_a_w_n() or _p_o_s_i_x___s_p_a_w_n_p(),
       implementations may open an unspecified file for the file descriptor in
       the new process image. If a standard utility or a conforming
       application is executed with file descriptor 0 not open for reading or
       with file descriptor 1 or 2 not open for writing, the environment in
       which the utility or application is executed shall be deemed non-
       conforming, and consequently the utility or application might not
       behave as described in this standard.

       The ppoossiixx__ssppaawwnnaattttrr__tt spawn attributes object type is defined in
       _<_s_p_a_w_n_._h_>.  It shall contain at least the attributes defined below.

       If the POSIX_SPAWN_SETPGROUP flag is set in the _s_p_a_w_n_-_f_l_a_g_s attribute
       of the object referenced by _a_t_t_r_p, and the _s_p_a_w_n_-_p_g_r_o_u_p attribute of
       the same object is non-zero, then the child's process group shall be as
       specified in the _s_p_a_w_n_-_p_g_r_o_u_p attribute of the object referenced by
       _a_t_t_r_p.

       As a special case, if the POSIX_SPAWN_SETPGROUP flag is set in the
       _s_p_a_w_n_-_f_l_a_g_s attribute of the object referenced by _a_t_t_r_p, and the _s_p_a_w_n_-
       _p_g_r_o_u_p attribute of the same object is set to zero, then the child
       shall be in a new process group with a process group ID equal to its
       process ID.

       If the POSIX_SPAWN_SETPGROUP flag is not set in the _s_p_a_w_n_-_f_l_a_g_s
       attribute of the object referenced by _a_t_t_r_p, the new child process
       shall inherit the parent's process group.

       If the POSIX_SPAWN_SETSCHEDPARAM flag is set in the _s_p_a_w_n_-_f_l_a_g_s
       attribute of the object referenced by _a_t_t_r_p, but
       POSIX_SPAWN_SETSCHEDULER is not set, the new process image shall
       initially have the scheduling policy of the calling process with the
       scheduling parameters specified in the _s_p_a_w_n_-_s_c_h_e_d_p_a_r_a_m attribute of
       the object referenced by _a_t_t_r_p.

       If the POSIX_SPAWN_SETSCHEDULER flag is set in the _s_p_a_w_n_-_f_l_a_g_s
       attribute of the object referenced by _a_t_t_r_p (regardless of the setting
       of the POSIX_SPAWN_SETSCHEDPARAM flag), the new process image shall
       initially have the scheduling policy specified in the _s_p_a_w_n_-_s_c_h_e_d_p_o_l_i_c_y
       attribute of the object referenced by _a_t_t_r_p and the scheduling
       parameters specified in the _s_p_a_w_n_-_s_c_h_e_d_p_a_r_a_m attribute of the same
       object.

       The POSIX_SPAWN_RESETIDS flag in the _s_p_a_w_n_-_f_l_a_g_s attribute of the
       object referenced by _a_t_t_r_p governs the effective user ID of the child
       process. If this flag is not set, the child process shall inherit the
       effective user ID of the parent process. If this flag is set, the
       effective user ID of the child process shall be reset to the parent's
       real user ID. In either case, if the set-user-ID mode bit of the new
       process image file is set, the effective user ID of the child process
       shall become that file's owner ID before the new process image begins
       execution.

       The POSIX_SPAWN_RESETIDS flag in the _s_p_a_w_n_-_f_l_a_g_s attribute of the
       object referenced by _a_t_t_r_p also governs the effective group ID of the
       child process. If this flag is not set, the child process shall inherit
       the effective group ID of the parent process. If this flag is set, the
       effective group ID of the child process shall be reset to the parent's
       real group ID. In either case, if the set-group-ID mode bit of the new
       process image file is set, the effective group ID of the child process
       shall become that file's group ID before the new process image begins
       execution.

       If the POSIX_SPAWN_SETSIGMASK flag is set in the _s_p_a_w_n_-_f_l_a_g_s attribute
       of the object referenced by _a_t_t_r_p, the child process shall initially
       have the signal mask specified in the _s_p_a_w_n_-_s_i_g_m_a_s_k attribute of the
       object referenced by _a_t_t_r_p.

       If the POSIX_SPAWN_SETSIGDEF flag is set in the _s_p_a_w_n_-_f_l_a_g_s attribute
       of the object referenced by _a_t_t_r_p, the signals specified in the _s_p_a_w_n_-
       _s_i_g_d_e_f_a_u_l_t attribute of the same object shall be set to their default
       actions in the child process. Signals set to the default action in the
       parent process shall be set to the default action in the child process.

       Signals set to be caught by the calling process shall be set to the
       default action in the child process.

       Except for SIGCHLD, signals set to be ignored by the calling process
       image shall be set to be ignored by the child process, unless otherwise
       specified by the POSIX_SPAWN_SETSIGDEF flag being set in the _s_p_a_w_n_-
       _f_l_a_g_s attribute of the object referenced by _a_t_t_r_p and the signals being
       indicated in the _s_p_a_w_n_-_s_i_g_d_e_f_a_u_l_t attribute of the object referenced by
       _a_t_t_r_p.

       If the SIGCHLD signal is set to be ignored by the calling process, it
       is unspecified whether the SIGCHLD signal is set to be ignored or to
       the default action in the child process, unless otherwise specified by
       the POSIX_SPAWN_SETSIGDEF flag being set in the _s_p_a_w_n___f_l_a_g_s attribute
       of the object referenced by _a_t_t_r_p and the SIGCHLD signal being
       indicated in the _s_p_a_w_n___s_i_g_d_e_f_a_u_l_t attribute of the object referenced by
       _a_t_t_r_p.

       If the value of the _a_t_t_r_p pointer is NULL, then the default values are
       used.

       All process attributes, other than those influenced by the attributes
       set in the object referenced by _a_t_t_r_p as specified above or by the file
       descriptor manipulations specified in _f_i_l_e___a_c_t_i_o_n_s, shall appear in the
       new process image as though _f_o_r_k() had been called to create a child
       process and then a member of the _e_x_e_c family of functions had been
       called by the child process to execute the new process image.

       It is implementation-defined whether the fork handlers are run when
       _p_o_s_i_x___s_p_a_w_n() or _p_o_s_i_x___s_p_a_w_n_p() is called.

RREETTUURRNN VVAALLUUEE
       Upon successful completion, _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() shall
       return the process ID of the child process to the parent process, in
       the variable pointed to by a non-NULL _p_i_d argument, and shall return
       zero as the function return value.  Otherwise, no child process shall
       be created, the value stored into the variable pointed to by a non-NULL
       _p_i_d is unspecified, and an error number shall be returned as the
       function return value to indicate the error. If the _p_i_d argument is a
       null pointer, the process ID of the child is not returned to the
       caller.

EERRRROORRSS
       These functions may fail if:

       EEIINNVVAALL The value specified by _f_i_l_e___a_c_t_i_o_n_s or _a_t_t_r_p is invalid.

       If this error occurs after the calling process successfully returns
       from the _p_o_s_i_x___s_p_a_w_n() or _p_o_s_i_x___s_p_a_w_n_p() function, the child process
       may exit with exit status 127.

       If _p_o_s_i_x___s_p_a_w_n() or _p_o_s_i_x___s_p_a_w_n_p() fail for any of the reasons that
       would cause _f_o_r_k() or one of the _e_x_e_c family of functions to fail, an
       error value shall be returned as described by _f_o_r_k() and _e_x_e_c,
       respectively (or, if the error occurs after the calling process
       successfully returns, the child process shall exit with exit status
       127).

       If POSIX_SPAWN_SETPGROUP is set in the _s_p_a_w_n_-_f_l_a_g_s attribute of the
       object referenced by _a_t_t_r_p, and _p_o_s_i_x___s_p_a_w_n() or _p_o_s_i_x___s_p_a_w_n_p() fails
       while changing the child's process group, an error value shall be
       returned as described by _s_e_t_p_g_i_d() (or, if the error occurs after the
       calling process successfully returns, the child process shall exit with
       exit status 127).

       If POSIX_SPAWN_SETSCHEDPARAM is set and POSIX_SPAWN_SETSCHEDULER is not
       set in the _s_p_a_w_n_-_f_l_a_g_s attribute of the object referenced by _a_t_t_r_p,
       then if _p_o_s_i_x___s_p_a_w_n() or _p_o_s_i_x___s_p_a_w_n_p() fails for any of the reasons
       that would cause _s_c_h_e_d___s_e_t_p_a_r_a_m() to fail, an error value shall be
       returned as described by _s_c_h_e_d___s_e_t_p_a_r_a_m() (or, if the error occurs
       after the calling process successfully returns, the child process shall
       exit with exit status 127).

       If POSIX_SPAWN_SETSCHEDULER is set in the _s_p_a_w_n_-_f_l_a_g_s attribute of the
       object referenced by _a_t_t_r_p, and if _p_o_s_i_x___s_p_a_w_n() or _p_o_s_i_x___s_p_a_w_n_p()
       fails for any of the reasons that would cause _s_c_h_e_d___s_e_t_s_c_h_e_d_u_l_e_r() to
       fail, an error value shall be returned as described by
       _s_c_h_e_d___s_e_t_s_c_h_e_d_u_l_e_r() (or, if the error occurs after the calling process
       successfully returns, the child process shall exit with exit status
       127).

       If the _f_i_l_e___a_c_t_i_o_n_s argument is not NULL, and specifies any _c_l_o_s_e,
       _d_u_p_2, or _o_p_e_n actions to be performed, and if _p_o_s_i_x___s_p_a_w_n() or
       _p_o_s_i_x___s_p_a_w_n_p() fails for any of the reasons that would cause _c_l_o_s_e(),
       _d_u_p_2(), or _o_p_e_n() to fail, an error value shall be returned as
       described by _c_l_o_s_e(), _d_u_p_2(), and _o_p_e_n(), respectively (or, if the
       error occurs after the calling process successfully returns, the child
       process shall exit with exit status 127). An open file action may, by
       itself, result in any of the errors described by _c_l_o_s_e() or _d_u_p_2(), in
       addition to those described by _o_p_e_n().

       _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
       These functions are part of the Spawn option and need not be provided
       on all implementations.

       See also the APPLICATION USAGE section for _e_x_e_c.

RRAATTIIOONNAALLEE
       The _p_o_s_i_x___s_p_a_w_n() function and its close relation _p_o_s_i_x___s_p_a_w_n_p() have
       been introduced to overcome the following perceived difficulties with
       _f_o_r_k(): the _f_o_r_k() function is difficult or impossible to implement
       without swapping or dynamic address translation.

        *  Swapping is generally too slow for a realtime environment.

        *  Dynamic address translation is not available everywhere that POSIX
           might be useful.

        *  Processes are too useful to simply option out of POSIX whenever it
           must run without address translation or other MMU services.

       Thus, POSIX needs process creation and file execution primitives that
       can be efficiently implemented without address translation or other MMU
       services.

       The _p_o_s_i_x___s_p_a_w_n() function is implementable as a library routine, but
       both _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() are designed as kernel
       operations. Also, although they may be an efficient replacement for
       many _f_o_r_k()/_e_x_e_c pairs, their goal is to provide useful process
       creation primitives for systems that have difficulty with _f_o_r_k(), not
       to provide drop-in replacements for _f_o_r_k()/_e_x_e_c.

       This view of the role of _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() influenced
       the design of their API. It does not attempt to provide the full
       functionality of _f_o_r_k()/_e_x_e_c in which arbitrary user-specified
       operations of any sort are permitted between the creation of the child
       process and the execution of the new process image; any attempt to
       reach that level would need to provide a programming language as
       parameters. Instead, _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() are process
       creation primitives like the _S_t_a_r_t___P_r_o_c_e_s_s and _S_t_a_r_t___P_r_o_c_e_s_s___S_e_a_r_c_h Ada
       language bindings package _P_O_S_I_X___P_r_o_c_e_s_s___P_r_i_m_i_t_i_v_e_s and also like those
       in many operating systems that are not UNIX systems, but with some
       POSIX-specific additions.

       To achieve its coverage goals, _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() have
       control of six types of inheritance: file descriptors, process group
       ID, user and group ID, signal mask, scheduling, and whether each signal
       ignored in the parent will remain ignored in the child, or be reset to
       its default action in the child.

       Control of file descriptors is required to allow an independently
       written child process image to access data streams opened by and even
       generated or read by the parent process without being specifically
       coded to know which parent files and file descriptors are to be used.
       Control of the process group ID is required to control how the job
       control of the child process relates to that of the parent.

       Control of the signal mask and signal defaulting is sufficient to
       support the implementation of _s_y_s_t_e_m().  Although support for _s_y_s_t_e_m()
       is not explicitly one of the goals for _p_o_s_i_x___s_p_a_w_n() and
       _p_o_s_i_x___s_p_a_w_n_p(), it is covered under the ``at least 50%'' coverage goal.

       The intention is that the normal file descriptor inheritance across
       _f_o_r_k(), the subsequent effect of the specified spawn file actions, and
       the normal file descriptor inheritance across one of the _e_x_e_c family of
       functions should fully specify open file inheritance. The
       implementation need make no decisions regarding the set of open file
       descriptors when the child process image begins execution, those
       decisions having already been made by the caller and expressed as the
       set of open file descriptors and their FD_CLOEXEC flags at the time of
       the call and the spawn file actions object specified in the call. We
       have been assured that in cases where the POSIX _S_t_a_r_t___P_r_o_c_e_s_s Ada
       primitives have been implemented in a library, this method of
       controlling file descriptor inheritance may be implemented very easily.

       We can identify several problems with _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p(),
       but there does not appear to be a solution that introduces fewer
       problems. Environment modification for child process attributes not
       specifiable via the _a_t_t_r_p or _f_i_l_e___a_c_t_i_o_n_s arguments must be done in the
       parent process, and since the parent generally wants to save its
       context, it is more costly than similar functionality with _f_o_r_k()/_e_x_e_c.
       It is also complicated to modify the environment of a multi-threaded
       process temporarily, since all threads must agree when it is safe for
       the environment to be changed. However, this cost is only borne by
       those invocations of _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() that use the
       additional functionality. Since extensive modifications are not the
       usual case, and are particularly unlikely in time-critical code,
       keeping much of the environment control out of _p_o_s_i_x___s_p_a_w_n() and
       _p_o_s_i_x___s_p_a_w_n_p() is appropriate design.

       The _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() functions do not have all the
       power of _f_o_r_k()/_e_x_e_c.  This is to be expected. The _f_o_r_k() function is a
       wonderfully powerful operation. We do not expect to duplicate its
       functionality in a simple, fast function with no special hardware
       requirements. It is worth noting that _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p()
       are very similar to the process creation operations on many operating
       systems that are not UNIX systems.

   RReeqquuiirreemmeennttss
       The requirements for _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() are:

        *  They must be implementable without an MMU or unusual hardware.

        *  They must be compatible with existing POSIX standards.

       Additional goals are:

        *  They should be efficiently implementable.

        *  They should be able to replace at least 50% of typical executions
           of _f_o_r_k().

        *  A system with _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() and without _f_o_r_k()
           should be useful, at least for realtime applications.

        *  A system with _f_o_r_k() and the _e_x_e_c family should be able to
           implement _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() as library routines.

   TTwwoo--SSyynnttaaxx
       POSIX _e_x_e_c has several calling sequences with approximately the same
       functionality. These appear to be required for compatibility with
       existing practice. Since the existing practice for the _p_o_s_i_x___s_p_a_w_n_*()
       functions is otherwise substantially unlike POSIX, we feel that
       simplicity outweighs compatibility. There are, therefore, only two
       names for the _p_o_s_i_x___s_p_a_w_n_*() functions.

       The parameter list does not differ between _p_o_s_i_x___s_p_a_w_n() and
       _p_o_s_i_x___s_p_a_w_n_p(); _p_o_s_i_x___s_p_a_w_n_p() interprets the second parameter more
       elaborately than _p_o_s_i_x___s_p_a_w_n().

   CCoommppaattiibbiilliittyy wwiitthh PPOOSSIIXX..55 ((AAddaa))
       The _S_t_a_r_t___P_r_o_c_e_s_s and _S_t_a_r_t___P_r_o_c_e_s_s___S_e_a_r_c_h procedures from the
       _P_O_S_I_X___P_r_o_c_e_s_s___P_r_i_m_i_t_i_v_e_s package from the Ada language binding to
       POSIX.1 encapsulate _f_o_r_k() and _e_x_e_c functionality in a manner similar
       to that of _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p().  Originally, in keeping
       with our simplicity goal, the standard developers had limited the
       capabilities of _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() to a subset of the
       capabilities of _S_t_a_r_t___P_r_o_c_e_s_s and _S_t_a_r_t___P_r_o_c_e_s_s___S_e_a_r_c_h; certain non-
       default capabilities were not supported. However, based on suggestions
       by the ballot group to improve file descriptor mapping or drop it, and
       on the advice of an Ada Language Bindings working group member, the
       standard developers decided that _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p()
       should be sufficiently powerful to implement _S_t_a_r_t___P_r_o_c_e_s_s and
       _S_t_a_r_t___P_r_o_c_e_s_s___S_e_a_r_c_h.  The rationale is that if the Ada language
       binding to such a primitive had already been approved as an IEEE
       standard, there can be little justification for not approving the
       functionally-equivalent parts of a C binding. The only three
       capabilities provided by _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() that are not
       provided by _S_t_a_r_t___P_r_o_c_e_s_s and _S_t_a_r_t___P_r_o_c_e_s_s___S_e_a_r_c_h are optionally
       specifying the child's process group ID, the set of signals to be reset
       to default signal handling in the child process, and the child's
       scheduling policy and parameters.

       For the Ada language binding for _S_t_a_r_t___P_r_o_c_e_s_s to be implemented with
       _p_o_s_i_x___s_p_a_w_n(), that binding would need to explicitly pass an empty
       signal mask and the parent's environment to _p_o_s_i_x___s_p_a_w_n() whenever the
       caller of _S_t_a_r_t___P_r_o_c_e_s_s allowed these arguments to default, since
       _p_o_s_i_x___s_p_a_w_n() does not provide such defaults. The ability of
       _S_t_a_r_t___P_r_o_c_e_s_s to mask user-specified signals during its execution is
       functionally unique to the Ada language binding and must be dealt with
       in the binding separately from the call to _p_o_s_i_x___s_p_a_w_n().

   PPrroocceessss GGrroouupp
       The process group inheritance field can be used to join the child
       process with an existing process group. By assigning a value of zero to
       the _s_p_a_w_n_-_p_g_r_o_u_p attribute of the object referenced by _a_t_t_r_p, the
       _s_e_t_p_g_i_d() mechanism will place the child process in a new process
       group.

   TThhrreeaaddss
       Without the _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() functions, systems without
       address translation can still use threads to give an abstraction of
       concurrency. In many cases, thread creation suffices, but it is not
       always a good substitute. The _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p()
       functions are considerably ``heavier'' than thread creation. Processes
       have several important attributes that threads do not. Even without
       address translation, a process may have base-and-bound memory
       protection. Each process has a process environment including security
       attributes and file capabilities, and powerful scheduling attributes.
       Processes abstract the behavior of non-uniform-memory-architecture
       multi-processors better than threads, and they are more convenient to
       use for activities that are not closely linked.

       The _p_o_s_i_x___s_p_a_w_n() and _p_o_s_i_x___s_p_a_w_n_p() functions may not bring support
       for multiple processes to every configuration. Process creation is not
       the only piece of operating system support required to support multiple
       processes. The total cost of support for multiple processes may be
       quite high in some circumstances. Existing practice shows that support
       for multiple processes is uncommon and threads are common among ``tiny
       kernels''.  There should, therefore, probably continue to be AEPs for
       operating systems with only one process.

   AAssyynncchhrroonnoouuss EErrrroorr NNoottiiffiiccaattiioonn
       A library implementation of _p_o_s_i_x___s_p_a_w_n() or _p_o_s_i_x___s_p_a_w_n_p() may not be
       able to detect all possible errors before it forks the child process.
       POSIX.1-2008 provides for an error indication returned from a child
       process which could not successfully complete the spawn operation via a
       special exit status which may be detected using the status value
       returned by _w_a_i_t(), _w_a_i_t_i_d(), and _w_a_i_t_p_i_d().

       The _s_t_a_t___v_a_l interface and the macros used to interpret it are not well
       suited to the purpose of returning API errors, but they are the only
       path available to a library implementation. Thus, an implementation may
       cause the child process to exit with exit status 127 for any error
       detected during the spawn process after the _p_o_s_i_x___s_p_a_w_n() or
       _p_o_s_i_x___s_p_a_w_n_p() function has successfully returned.

       The standard developers had proposed using two additional macros to
       interpret _s_t_a_t___v_a_l.  The first, WIFSPAWNFAIL, would have detected a
       status that indicated that the child exited because of an error
       detected during the _p_o_s_i_x___s_p_a_w_n() or _p_o_s_i_x___s_p_a_w_n_p() operations rather
       than during actual execution of the child process image; the second,
       WSPAWNERRNO, would have extracted the error value if WIFSPAWNFAIL
       indicated a failure. Unfortunately, the ballot group strongly opposed
       this because it would make a library implementation of _p_o_s_i_x___s_p_a_w_n() or
       _p_o_s_i_x___s_p_a_w_n_p() dependent on kernel modifications to _w_a_i_t_p_i_d() to be
       able to embed special information in _s_t_a_t___v_a_l to indicate a spawn
       failure.

       The 8 bits of child process exit status that are guaranteed by
       POSIX.1-2008 to be accessible to the waiting parent process are
       insufficient to disambiguate a spawn error from any other kind of error
       that may be returned by an arbitrary process image. No other bits of
       the exit status are required to be visible in _s_t_a_t___v_a_l, so these macros
       could not be strictly implemented at the library level.  Reserving an
       exit status of 127 for such spawn errors is consistent with the use of
       this value by _s_y_s_t_e_m() and _p_o_p_e_n() to signal failures in these
       operations that occur after the function has returned but before a
       shell is able to execute. The exit status of 127 does not uniquely
       identify this class of error, nor does it provide any detailed
       information on the nature of the failure. Note that a kernel
       implementation of _p_o_s_i_x___s_p_a_w_n() or _p_o_s_i_x___s_p_a_w_n_p() is permitted (and
       encouraged) to return any possible error as the function value, thus
       providing more detailed failure information to the parent process.

       Thus, no special macros are available to isolate asynchronous
       _p_o_s_i_x___s_p_a_w_n() or _p_o_s_i_x___s_p_a_w_n_p() errors. Instead, errors detected by the
       _p_o_s_i_x___s_p_a_w_n() or _p_o_s_i_x___s_p_a_w_n_p() operations in the context of the child
       process before the new process image executes are reported by setting
       the child's exit status to 127.  The calling process may use the
       WIFEXITED and WEXITSTATUS macros on the _s_t_a_t___v_a_l stored by the _w_a_i_t()
       or _w_a_i_t_p_i_d() functions to detect spawn failures to the extent that
       other status values with which the child process image may exit (before
       the parent can conclusively determine that the child process image has
       begun execution) are distinct from exit status 127.

FFUUTTUURREE DDIIRREECCTTIIOONNSS
       None.

SSEEEE AALLSSOO
       _a_l_a_r_m(), _c_h_m_o_d(), _c_l_o_s_e(), _d_u_p(), _e_x_e_c, _e_x_i_t(), _f_c_n_t_l(), _f_o_r_k(),
       _f_s_t_a_t_a_t(), _k_i_l_l(), _o_p_e_n(), _p_o_s_i_x___s_p_a_w_n___f_i_l_e___a_c_t_i_o_n_s___a_d_d_c_l_o_s_e(),
       _p_o_s_i_x___s_p_a_w_n___f_i_l_e___a_c_t_i_o_n_s___a_d_d_d_u_p_2(), _p_o_s_i_x___s_p_a_w_n___f_i_l_e___a_c_t_i_o_n_s___d_e_s_t_r_o_y(),
       _p_o_s_i_x___s_p_a_w_n_a_t_t_r___d_e_s_t_r_o_y(), _p_o_s_i_x___s_p_a_w_n_a_t_t_r___g_e_t_s_i_g_d_e_f_a_u_l_t(),
       _p_o_s_i_x___s_p_a_w_n_a_t_t_r___g_e_t_f_l_a_g_s(), _p_o_s_i_x___s_p_a_w_n_a_t_t_r___g_e_t_p_g_r_o_u_p(),
       _p_o_s_i_x___s_p_a_w_n_a_t_t_r___g_e_t_s_c_h_e_d_p_a_r_a_m(), _p_o_s_i_x___s_p_a_w_n_a_t_t_r___g_e_t_s_c_h_e_d_p_o_l_i_c_y(),
       _p_o_s_i_x___s_p_a_w_n_a_t_t_r___g_e_t_s_i_g_m_a_s_k(), _s_c_h_e_d___s_e_t_p_a_r_a_m(), _s_c_h_e_d___s_e_t_s_c_h_e_d_u_l_e_r(),
       _s_e_t_p_g_i_d(), _s_e_t_u_i_d(), _t_i_m_e_s(), _w_a_i_t(), _w_a_i_t_i_d()

       The Base Definitions volume of POSIX.1-2017, _C_h_a_p_t_e_r _8, _E_n_v_i_r_o_n_m_e_n_t
       _V_a_r_i_a_b_l_e_s, <<ssppaawwnn..hh>>

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

       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                  2017                       POSIX_SPAWN(3)
