порождать процесс (spawn a process)
Описание (Description)
The posix_spawn() and posix_spawnp() functions are used to create
a new child process that executes a specified file. These
functions were specified by POSIX to provide a standardized
method of creating new processes on machines that lack the
capability to support the fork(2) system call. These machines
are generally small, embedded systems lacking MMU support.
The posix_spawn() and posix_spawnp() functions provide the
functionality of a combined fork(2) and exec(3), with some
optional housekeeping steps in the child process before the
exec(3). These functions are not meant to replace the fork(2)
and execve(2) system calls. In fact, they provide only a subset
of the functionality that can be achieved by using the system
calls.
The only difference between posix_spawn() and posix_spawnp() is
the manner in which they specify the file to be executed by the
child process. With posix_spawn(), the executable file is
specified as a pathname (which can be absolute or relative).
With posix_spawnp(), the executable file is specified as a simple
filename; the system searches for this file in the list of
directories specified by PATH (in the same way as for execvp(3)).
For the remainder of this page, the discussion is phrased in
terms of posix_spawn(), with the understanding that
posix_spawnp() differs only on the point just described.
The remaining arguments to these two functions are as follows:
* The pid argument points to a buffer that is used to return the
process ID of the new child process.
* The file_actions argument points to a spawn file actions
object that specifies file-related actions to be performed in
the child between the fork(2) and exec(3) steps. This object
is initialized and populated before the posix_spawn() call
using posix_spawn_file_actions_init(3) and the
posix_spawn_file_actions_*() functions.
* The attrp argument points to an attributes objects that
specifies various attributes of the created child process.
This object is initialized and populated before the
posix_spawn() call using posix_spawnattr_init(3) and the
posix_spawnattr_*() functions.
* The argv and envp arguments specify the argument list and
environment for the program that is executed in the child
process, as for execve(2).
Below, the functions are described in terms of a three-step
process: the fork() step, the pre-exec() step (executed in the
child), and the exec() step (executed in the child).
fork() step
Since glibc 2.24, the posix_spawn() function commences by calling
clone(2) with CLONE_VM and CLONE_VFORK flags. Older
implementations use fork(2), or possibly vfork(2) (see below).
The PID of the new child process is placed in *pid. The
posix_spawn() function then returns control to the parent
process.
Subsequently, the parent can use one of the system calls
described in wait(2) to check the status of the child process.
If the child fails in any of the housekeeping steps described
below, or fails to execute the desired file, it exits with a
status of 127.
Before glibc 2.24, the child process is created using vfork(2)
instead of fork(2) when either of the following is true:
* the spawn-flags element of the attributes object pointed to by
attrp contains the GNU-specific flag POSIX_SPAWN_USEVFORK; or
* file_actions is NULL and the spawn-flags element of the
attributes object pointed to by attrp does not contain
POSIX_SPAWN_SETSIGMASK, POSIX_SPAWN_SETSIGDEF,
POSIX_SPAWN_SETSCHEDPARAM, POSIX_SPAWN_SETSCHEDULER,
POSIX_SPAWN_SETPGROUP, or POSIX_SPAWN_RESETIDS.
In other words, vfork(2) is used if the caller requests it, or if
there is no cleanup expected in the child before it exec(3)s the
requested file.
pre-exec() step: housekeeping
In between the fork() and the exec() steps, a child process may
need to perform a set of housekeeping actions. The posix_spawn()
and posix_spawnp() functions support a small, well-defined set of
system tasks that the child process can accomplish before it
executes the executable file. These operations are controlled by
the attributes object pointed to by attrp and the file actions
object pointed to by file_actions. In the child, processing is
done in the following sequence:
1. Process attribute actions: signal mask, signal default
handlers, scheduling algorithm and parameters, process group,
and effective user and group IDs are changed as specified by
the attributes object pointed to by attrp.
2. File actions, as specified in the file_actions argument, are
performed in the order that they were specified using calls to
the posix_spawn_file_actions_add*() functions.
3. File descriptors with the FD_CLOEXEC flag set are closed.
All process attributes in the child, other than those affected by
attributes specified in the object pointed to by attrp and the
file actions in the object pointed to by file_actions, will be
affected as though the child was created with fork(2) and it
executed the program with execve(2).
The process attributes actions are defined by the attributes
object pointed to by attrp. The spawn-flags attribute (set using
posix_spawnattr_setflags(3)) controls the general actions that
occur, and other attributes in the object specify values to be
used during those actions.
The effects of the flags that may be specified in spawn-flags are
as follows:
POSIX_SPAWN_SETSIGMASK
Set the signal mask to the signal set specified in the
spawn-sigmask attribute of the object pointed to by attrp.
If the POSIX_SPAWN_SETSIGMASK flag is not set, then the
child inherits the parent's signal mask.
POSIX_SPAWN_SETSIGDEF
Reset the disposition of all signals in the set specified
in the spawn-sigdefault attribute of the object pointed to
by attrp to the default. For the treatment of the
dispositions of signals not specified in the spawn-
sigdefault attribute, or the treatment when
POSIX_SPAWN_SETSIGDEF is not specified, see execve(2).
POSIX_SPAWN_SETSCHEDPARAM
If this flag is set, and the POSIX_SPAWN_SETSCHEDULER flag
is not set, then set the scheduling parameters to the
parameters specified in the spawn-schedparam attribute of
the object pointed to by attrp.
POSIX_SPAWN_SETSCHEDULER
Set the scheduling policy algorithm and parameters of the
child, as follows:
* The scheduling policy is set to the value specified in
the spawn-schedpolicy attribute of the object pointed
to by attrp.
* The scheduling parameters are set to the value
specified in the spawn-schedparam attribute of the
object pointed to by attrp (but see BUGS).
If the POSIX_SPAWN_SETSCHEDPARAM and
POSIX_SPAWN_SETSCHEDPOLICY flags are not specified, the
child inherits the corresponding scheduling attributes
from the parent.
POSIX_SPAWN_RESETIDS
If this flag is set, reset the effective UID and GID to
the real UID and GID of the parent process. If this flag
is not set, then the child retains the effective UID and
GID of the parent. In either case, if the set-user-ID and
set-group-ID permission bits are enabled on the executable
file, their effect will override the setting of the
effective UID and GID (se execve(2)).
POSIX_SPAWN_SETPGROUP
Set the process group to the value specified in the spawn-
pgroup attribute of the object pointed to by attrp. If
the spawn-pgroup attribute has the value 0, the child's
process group ID is made the same as its process ID. If
the POSIX_SPAWN_SETPGROUP flag is not set, the child
inherits the parent's process group ID.
POSIX_SPAWN_USEVFORK
Since glibc 2.24, this flag has no effect. On older
implementations, setting this flag forces the fork() step
to use vfork(2) instead of fork(2). The _GNU_SOURCE
feature test macro must be defined to obtain the
definition of this constant.
POSIX_SPAWN_SETSID (since glibc 2.26)
If this flag is set, the child process shall create a new
session and become the session leader. The child process
shall also become the process group leader of the new
process group in the session (see setsid(2)). The
_GNU_SOURCE feature test macro must be defined to obtain
the definition of this constant.
If attrp is NULL, then the default behaviors described above for
each flag apply.
The file_actions argument specifies a sequence of file operations
that are performed in the child process after the general
processing described above, and before it performs the exec(3).
If file_actions is NULL, then no special action is taken, and
standard exec(3) semantics apply—file descriptors open before the
exec remain open in the new process, except those for which the
FD_CLOEXEC flag has been set. File locks remain in place.
If file_actions is not NULL, then it contains an ordered set of
requests to open(2), close(2), and dup2(2) files. These requests
are added to the file_actions by
posix_spawn_file_actions_addopen(3),
posix_spawn_file_actions_addclose(3), and
posix_spawn_file_actions_adddup2(3). The requested operations
are performed in the order they were added to file_actions.
If any of the housekeeping actions fails (due to bogus values
being passed or other reasons why signal handling, process
scheduling, process group ID functions, and file descriptor
operations might fail), the child process exits with exit value
127.
exec() step
Once the child has successfully forked and performed all
requested pre-exec steps, the child runs the requested
executable.
The child process takes its environment from the envp argument,
which is interpreted as if it had been passed to execve(2). The
arguments to the created process come from the argv argument,
which is processed as for execve(2).
