POSIX_SPAWN(3P) POSIX Programmer's Manual POSIX_SPAWN(3P)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
posix_spawn, posix_spawnp - spawn a process (ADVANCED REALTIME)
SYNOPSIS
#include <spawn.h>
int posix_spawn(pid_t *restrict pid, const char *restrict path,
const posix_spawn_file_actions_t *file_actions,
const posix_spawnattr_t *restrict attrp,
char *const argv[restrict], char *const envp[restrict]);
int posix_spawnp(pid_t *restrict pid, const char *restrict file,
const posix_spawn_file_actions_t *file_actions,
const posix_spawnattr_t *restrict attrp,
char *const argv[restrict], char * const envp[restrict]);
DESCRIPTION
The posix_spawn() and posix_spawnp() 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 argc, char *argv[]);
where argc is the argument count and argv is an array of character
pointers to the arguments themselves. In addition, the following vari‐
able:
extern char **environ;
shall be initialized as a pointer to an array of character pointers to
the environment strings.
The argument argv 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 argc. These strings constitute the argument list avail‐
able to the new process image. The value in argv[0] should point to a
filename that is associated with the process image being started by the
posix_spawn() or posix_spawnp() function.
The argument envp 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 child process' combined argument
and environment lists is {ARG_MAX}. The implementation shall specify in
the system documentation (see the Base Definitions volume of
IEEE Std 1003.1-2001, Chapter 2, Conformance) whether any list over‐
head, such as length words, null terminators, pointers, or alignment
bytes, is included in this total.
The path argument to posix_spawn() is a pathname that identifies the
new process image file to execute.
The file parameter to posix_spawnp() shall be used to construct a path‐
name that identifies the new process image file. If the file parameter
contains a slash character, the file 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 PATH (see the Base Definitions volume of
IEEE Std 1003.1-2001, Chapter 8, Environment Variables). If this envi‐
ronment variable is not defined, the results of the search are imple‐
mentation-defined.
If file_actions 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- exec flag FD_CLOEXEC is set (see fcntl()). For
those file descriptors that remain open, all attributes of the corre‐
sponding open file descriptions, including file locks (see fcntl()),
shall remain unchanged.
If file_actions 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 file_actions 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 ini‐
tially be the same set as is open for the calling process. All
attributes of the corresponding open file descriptions, including
file locks (see fcntl()), 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 attrp.
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 fcntl() )
shall be closed.
The posix_spawnattr_t spawn attributes object type is defined in
<spawn.h>. It shall contain at least the attributes defined below.
If the POSIX_SPAWN_SETPGROUP flag is set in the spawn-flags attribute
of the object referenced by attrp, and the spawn-pgroup attribute of
the same object is non-zero, then the child's process group shall be as
specified in the spawn-pgroup attribute of the object referenced by
attrp.
As a special case, if the POSIX_SPAWN_SETPGROUP flag is set in the
spawn-flags attribute of the object referenced by attrp, and the spawn-
pgroup 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 spawn-flags
attribute of the object referenced by attrp, the new child process
shall inherit the parent's process group.
If the POSIX_SPAWN_SETSCHEDPARAM flag is set in the spawn-flags
attribute of the object referenced by attrp, but POSIX_SPAWN_SETSCHED‐
ULER is not set, the new process image shall initially have the sched‐
uling policy of the calling process with the scheduling parameters
specified in the spawn-schedparam attribute of the object referenced by
attrp.
If the POSIX_SPAWN_SETSCHEDULER flag is set in the spawn-flags
attribute of the object referenced by attrp (regardless of the setting
of the POSIX_SPAWN_SETSCHEDPARAM flag), the new process image shall
initially have the scheduling policy specified in the spawn-schedpolicy
attribute of the object referenced by attrp and the scheduling parame‐
ters specified in the spawn-schedparam attribute of the same object.
The POSIX_SPAWN_RESETIDS flag in the spawn-flags attribute of the
object referenced by attrp governs the effective user ID of the child
process. If this flag is not set, the child process shall inherit the
parent process' effective user ID. If this flag is set, the child
process' effective user ID 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 spawn-flags attribute of the
object referenced by attrp also governs the effective group ID of the
child process. If this flag is not set, the child process shall inherit
the parent process' effective group ID. If this flag is set, the child
process' effective group ID 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 execu‐
tion.
If the POSIX_SPAWN_SETSIGMASK flag is set in the spawn-flags attribute
of the object referenced by attrp, the child process shall initially
have the signal mask specified in the spawn-sigmask attribute of the
object referenced by attrp.
If the POSIX_SPAWN_SETSIGDEF flag is set in the spawn-flags attribute
of the object referenced by attrp, the signals specified in the spawn-
sigdefault 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 spawn-
flags attribute of the object referenced by attrp and the signals being
indicated in the spawn-sigdefault attribute of the object referenced by
attrp.
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 spawn_flags attribute
of the object referenced by attrp and the SIGCHLD signal being indi‐
cated in the spawn_sigdefault attribute of the object referenced by
attrp.
If the value of the attrp 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 attrp as specified above or by the file
descriptor manipulations specified in file_actions, shall appear in the
new process image as though fork() had been called to create a child
process and then a member of the exec 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
posix_spawn() or posix_spawnp() is called.
RETURN VALUE
Upon successful completion, posix_spawn() and posix_spawnp() shall
return the process ID of the child process to the parent process, in
the variable pointed to by a non-NULL pid 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
pid is unspecified, and an error number shall be returned as the func‐
tion return value to indicate the error. If the pid argument is a null
pointer, the process ID of the child is not returned to the caller.
ERRORS
The posix_spawn() and posix_spawnp() functions may fail if:
EINVAL The value specified by file_actions or attrp is invalid.
If this error occurs after the calling process successfully returns
from the posix_spawn() or posix_spawnp() function, the child process
may exit with exit status 127.
If posix_spawn() or posix_spawnp() fail for any of the reasons that
would cause fork() or one of the exec family of functions to fail, an
error value shall be returned as described by fork() and exec, respec‐
tively (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 spawn-flags attribute of the
object referenced by attrp, and posix_spawn() or posix_spawnp() fails
while changing the child's process group, an error value shall be
returned as described by setpgid() (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 spawn-flags attribute of the object referenced by attrp,
then if posix_spawn() or posix_spawnp() fails for any of the reasons
that would cause sched_setparam() to fail, an error value shall be
returned as described by sched_setparam() (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 spawn-flags attribute of the
object referenced by attrp, and if posix_spawn() or posix_spawnp()
fails for any of the reasons that would cause sched_setscheduler() to
fail, an error value shall be returned as described by sched_setsched‐
uler() (or, if the error occurs after the calling process successfully
returns, the child process shall exit with exit status 127).
If the file_actions argument is not NULL, and specifies any close,
dup2, or open actions to be performed, and if posix_spawn() or
posix_spawnp() fails for any of the reasons that would cause close(),
dup2(), or open() to fail, an error value shall be returned as
described by close(), dup2(), and open(), 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 close() or dup2(), in
addition to those described by open().
The following sections are informative.
EXAMPLES
None.
APPLICATION USAGE
These functions are part of the Spawn option and need not be provided
on all implementations.
RATIONALE
The posix_spawn() function and its close relation posix_spawnp() have
been introduced to overcome the following perceived difficulties with
fork(): the fork() 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 posix_spawn() function is implementable as a library routine, but
both posix_spawn() and posix_spawnp() are designed as kernel opera‐
tions. Also, although they may be an efficient replacement for many
fork()/ exec pairs, their goal is to provide useful process creation
primitives for systems that have difficulty with fork(), not to provide
drop-in replacements for fork()/ exec.
This view of the role of posix_spawn() and posix_spawnp() influenced
the design of their API. It does not attempt to provide the full func‐
tionality of fork()/ exec 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,
posix_spawn() and posix_spawnp() are process creation primitives like
the Start_Process and Start_Process_Search Ada language bindings pack‐
age POSIX_Process_Primitives and also like those in many operating sys‐
tems that are not UNIX systems, but with some POSIX-specific additions.
To achieve its coverage goals, posix_spawn() and posix_spawnp() 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 writ‐
ten child process image to access data streams opened by and even gen‐
erated 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 child process'
job control relates to that of the parent.
Control of the signal mask and signal defaulting is sufficient to sup‐
port the implementation of system(). Although support for system() is
not explicitly one of the goals for posix_spawn() and posix_spawnp(),
it is covered under the "at least 50%" coverage goal.
The intention is that the normal file descriptor inheritance across
fork(), the subsequent effect of the specified spawn file actions, and
the normal file descriptor inheritance across one of the exec family of
functions should fully specify open file inheritance. The implementa‐
tion 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 Start_Process 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 posix_spawn() and posix_spawnp(),
but there does not appear to be a solution that introduces fewer prob‐
lems. Environment modification for child process attributes not speci‐
fiable via the attrp or file_actions arguments must be done in the par‐
ent process, and since the parent generally wants to save its context,
it is more costly than similar functionality with fork()/ exec. 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 envi‐
ronment to be changed. However, this cost is only borne by those invo‐
cations of posix_spawn() and posix_spawnp() 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 posix_spawn() and posix_spawnp() is
appropriate design.
The posix_spawn() and posix_spawnp() functions do not have all the
power of fork()/ exec. This is to be expected. The fork() 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 posix_spawn() and posix_spawnp()
are very similar to the process creation operations on many operating
systems that are not UNIX systems.
Requirements
The requirements for posix_spawn() and posix_spawnp() 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
fork().
* A system with posix_spawn() and posix_spawnp() and without fork()
should be useful, at least for realtime applications.
* A system with fork() and the exec family should be able to implement
posix_spawn() and posix_spawnp() as library routines.
Two-Syntax
POSIX exec 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 posix_spawn*()
functions is otherwise substantially unlike POSIX, we feel that sim‐
plicity outweighs compatibility. There are, therefore, only two names
for the posix_spawn*() functions.
The parameter list does not differ between posix_spawn() and
posix_spawnp(); posix_spawnp() interprets the second parameter more
elaborately than posix_spawn().
Compatibility with POSIX.5 (Ada)
The Start_Process and Start_Process_Search procedures from the
POSIX_Process_Primitives package from the Ada language binding to
POSIX.1 encapsulate fork() and exec functionality in a manner similar
to that of posix_spawn() and posix_spawnp(). Originally, in keeping
with our simplicity goal, the standard developers had limited the capa‐
bilities of posix_spawn() and posix_spawnp() to a subset of the capa‐
bilities of Start_Process and Start_Process_Search; 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 posix_spawn() and posix_spawnp() should be suf‐
ficiently powerful to implement Start_Process and Start_Process_Search.
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 jus‐
tification for not approving the functionally-equivalent parts of a C
binding. The only three capabilities provided by posix_spawn() and
posix_spawnp() that are not provided by Start_Process and
Start_Process_Search 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 Start_Process to be implemented with
posix_spawn(), that binding would need to explicitly pass an empty sig‐
nal mask and the parent's environment to posix_spawn() whenever the
caller of Start_Process allowed these arguments to default, since
posix_spawn() does not provide such defaults. The ability of
Start_Process 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 posix_spawn().
Process Group
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 spawn-pgroup attribute of the object referenced by attrp, the
setpgid() mechanism will place the child process in a new process
group.
Threads
Without the posix_spawn() and posix_spawnp() 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 posix_spawn() and posix_spawnp() func‐
tions 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-proces‐
sors better than threads, and they are more convenient to use for
activities that are not closely linked.
The posix_spawn() and posix_spawnp() 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.
Asynchronous Error Notification
A library implementation of posix_spawn() or posix_spawnp() may not be
able to detect all possible errors before it forks the child process.
IEEE Std 1003.1-2001 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 wait() and waitpid().
The stat_val 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 posix_spawn() or
posix_spawnp() function has successfully returned.
The standard developers had proposed using two additional macros to
interpret stat_val. The first, WIFSPAWNFAIL, would have detected a sta‐
tus that indicated that the child exited because of an error detected
during the posix_spawn() or posix_spawnp() operations rather than dur‐
ing actual execution of the child process image; the second, WSPAWN‐
ERRNO, 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 posix_spawn() or
posix_spawnp() dependent on kernel modifications to waitpid() to be
able to embed special information in stat_val to indicate a spawn fail‐
ure.
The 8 bits of child process exit status that are guaranteed by
IEEE Std 1003.1-2001 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 stat_val, 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 system() and popen() to signal failures in these opera‐
tions 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
posix_spawn() or posix_spawnp() 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
posix_spawn() or posix_spawnp() errors. Instead, errors detected by the
posix_spawn() or posix_spawnp() 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 WIFEX‐
ITED and WEXITSTATUS macros on the stat_val stored by the wait() or
waitpid() 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.
FUTURE DIRECTIONS
None.
SEE ALSOalarm(), chmod(), close(), dup(), exec(), exit(), fcntl(), fork(),
kill(), open(), posix_spawn_file_actions_addclose(),
posix_spawn_file_actions_adddup2(), posix_spawn_file_actions_addopen(),
posix_spawn_file_actions_destroy(), posix_spawnattr_destroy(),
posix_spawnattr_init(), posix_spawnattr_getsigdefault(), posix_spaw‐
nattr_getflags(), posix_spawnattr_getpgroup(), posix_spaw‐
nattr_getschedparam(), posix_spawnattr_getschedpolicy(), posix_spaw‐
nattr_getsigmask(), posix_spawnattr_setsigdefault(), posix_spaw‐
nattr_setflags(), posix_spawnattr_setpgroup(), posix_spaw‐
nattr_setschedparam(), posix_spawnattr_setschedpolicy(), posix_spaw‐
nattr_setsigmask(), sched_setparam(), sched_setscheduler(), setpgid(),
setuid(), stat(), times(), wait(), the Base Definitions volume of
IEEE Std 1003.1-2001, <spawn.h>
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 .
IEEE/The Open Group 2003 POSIX_SPAWN(3P)
