Description:
The spawn() function creates and executes a new child process, named in path.
Note:
- In order to create a child process, your process must have the
PROCMGR_AID_SPAWN ability enabled.
In order to create a new application ID for the child process, your process must have the
PROCMGR_AID_CHILD_NEWAPP ability enabled.
- If the new child process is a shell script, the first line must start with
#!, followed by the path of the program to run
to interpret the script, optionally followed by one argument.
The script must also be marked as executable.
For more information, see
The first line
in the Writing Shell Scripts chapter of the
QNX Neutrino User's Guide.
- If the child will link a library at load time or at run time (i.e., with dlopen()), the child must be given the
PROCMGR_AID_PROT_EXEC and PROCMGR_AID_MAP_FIXED abilities. For more information, see
procmgr_ability().
The spawn() function is provided for backwards compatibility with older
versions of QNX Neutrino. Instead, use posix_spawn(). The C library also includes other specialized
spawn*() convenience functions. Their names consist of
spawn followed by a letter or letters.
The child process inherits the following attributes of the parent process or thread (as appropriate):
- process group ID (unless SPAWN_SETGROUP is set in inherit->flags)
- session membership
- real user ID and real group ID
- effective user ID and effective group ID
- supplementary group IDs
- priority and scheduling policy
- current working directory and root directory
- file-creation mask
- signal mask (unless SPAWN_SETSIGMASK is set in inherit->flags)
- signal actions specified as SIG_DFL
- signal actions specified as SIG_IGN (except the
ones modified by inherit->sigdefault when
SPAWN_SETSIGDEF is set in inherit->flags).
- the Address Space Layout Randomization setting; the child uses ASLR if the parent uses it.
You can use the SPAWN_ASLR_INVERT bit in inherit->flags to toggle this setting.
The child process has several differences from the parent process or thread (as appropriate):
- Signals set to be caught by the parent process are set to the
default action (SIG_DFL).
- The child process's tms_utime, tms_stime,
tms_cutime, and tms_cstime are tracked separately
from the parent's.
- File locks set by the parent aren't inherited.
- Per-process timers created by the parent aren't inherited.
- Memory locks and mappings set by the parent aren't inherited.
- The child doesn't inherit the parent's default timer tolerance (set by a call to
procmgr_timer_tolerance()).
The child process also has these differences from the parent process
if you haven't set the SPAWN_EXEC flag:
- The number of seconds left until a SIGALRM signal
would be generated is set to zero for the child process.
- The set of pending signals for the child process is empty.
The child process can access its environment by using the
environ
global variable (found in <unistd.h>).
If the path is on a filesystem mounted with the ST_NOSUID flag set,
the effective user ID, effective group ID, saved set-user ID and saved set-group ID are unchanged for the child process.
Otherwise, if the set-user ID mode bit is set, the effective user ID of the child process is set
to the owner ID of path.
Similarly, if the set-group ID mode bit is set, the effective group ID of the child process
is set to the group ID of path.
The real user ID, real group ID and supplementary group IDs of the child process remain the same as
those of the parent process.
The effective user ID and effective group ID of the child process are saved as the saved set-user ID and
the saved set-group ID used by the
setuid().
Note:
A parent/child relationship doesn't imply that the child process dies when the parent process dies.
Mapping file descriptors
As described above, you can use the fd_count and fd_map
arguments to specify which file descriptors you want the child process to
inherit.
The number used for a file descriptor in the child process depends
on its position in
fd_map, not on the actual file descriptor
in the parent.
For example, suppose the parent has file descriptors valued 1, 3, and 5
that you want to have in the child process.
If you specify:
int fd_map = { 1, 3, 5 };
then the mapping is as follows:
In the child, this fd: |
Is the same as this fd in the parent: |
0 |
1 |
1 |
3 |
2 |
5 |
If 1, 3, and 5 are the only file descriptors open in the parent, and you
specify an
fd_count of 0, the function duplicates all
the file descriptors:
In the child, this fd: |
Is the same as this fd in the parent: |
1 |
1 |
3 |
3 |
5 |
5 |
and file descriptors 0, 2, 4, and 6 (and higher) are closed.
If you're using an explicit
fd_map, then in order to get
numerically matching file descriptors in the child and the parent, you
must fill the holes in the map with
SPAWN_FDCLOSED:
int fd_map = { SPAWN_FDCLOSED, 1, SPAWN_FDCLOSED, 3, SPAWN_FDCLOSED, 5 };
Note:
Be careful if you use
SPAWN_FDCLOSED for file descriptors 0, 1, and 2.
If the child process calls
open(),
the function assigns the lowest numbered unused file descriptor.
If, for example, you set
stdout or 1 to
SPAWN_FDCLOSED, the next
open() in the spawned
application is assigned file descriptor 1.
In this case,
printf()
would write to whatever resource was opened, which may or may not be
what you intended.
It's safer to set 0, 1 and 2 to be the file descriptor from an
open() of a known resource (such as /dev/null)
in the parent, and then pass those file descriptors to the child.
inheritance structure
The inheritance structure contains at least these members:
- uint32_t flags
- Zero or more of the following bits:
- SPAWN_ALIGN_DEFAULT — use the system's default
settings for alignment.
- SPAWN_ALIGN_FAULT — try to always fault data
misalignment references.
- SPAWN_ALIGN_NOFAULT — don't fault on misalignment;
attempt to fix it (this may be slow).
- SPAWN_ASLR_INVERT — toggle the Address Space Layout Randomization bit.
If the parent has ASLR enabled, turn it off for the child;
if the parent's bit is off, turn it on for the child.
- SPAWN_CHECK_SCRIPT — if unable to run
path in any other way,
start a shell, passing path as a script.
- SPAWN_CRITICAL (QNX Neutrino 7.0.4 or later) — indicate that the new
process is critical to system functionality, meaning if the process dies, the system
will crash. To create a critical process with SPAWN_CRITICAL, your
process needs the PROCMGR_AID_REBOOT ability. For more information,
see procmgr_ability().
- SPAWN_DEBUG — debug process (this is used only
for debugging the kernel itself).
- SPAWN_EXEC — cause the spawn to act like
exec*(): replace the calling program in memory with the
newly loaded program.
If successful, no return is made to the calling program.
- SPAWN_EXPLICIT_CPU —
(QNX Neutrino Core OS 6.3.2 or later)
Set the runmask and inherit mask equal
to the runmask member of the inheritance structure.
If this flag isn't set,
the child inherits the inherit mask of the calling thread.
- SPAWN_EXPLICIT_SCHED — set the scheduling policy
to the value of the policy member, and the scheduling parameters
to the value of the param member.
- SPAWN_HOLD — hold a process for debugging
(i.e., send the SIGSTOP signal to the process before it
executes its first instruction).
- SPAWN_NEWAPP — assign a new application ID to the process.
If you don't set this flag, the process inherits the parent's application ID.
For
more information, see "Application groups" in the QNX Neutrino System Security Guide.
- SPAWN_NOZOMBIE — prevent the child process from
becoming a zombie on its death.
No child return or exit information will be available.
- SPAWN_SETGROUP — set the child's process group to
the value in the pgroup member.
If this flag isn't set, the child process is part of the current
process group.
- SPAWN_SETSID — make the new process a session
leader.
- SPAWN_SETSIGDEF — use the sigdefault
member to specify the child process's set of defaulted signals.
If you don't specify this flag, the child process inherits the
parent process's signal actions.
- SPAWN_SETSIGIGN — set the handling for signals
defined in the sigignore member to SIG_IGN.
- SPAWN_SETSIGMASK — use the sigmask
member to specify the child process's signal mask.
- SPAWN_SETSTACKMAX — set the maximum stack size
to the value of the stack_max member.
- SPAWN_TCSETPGROUP — start a new terminal group.
The <spawn.h> file also defines
SPAWN_ALIGN_MASK. It's a mask for the alignment flags listed
above.
- pid_t pgroup
- The child process's group if you specify SPAWN_SETGROUP
in the flags member.
If SPAWN_SETGROUP is set in inherit->flags and
inherit->pgroup is set to SPAWN_NEWPGROUP, the
child process starts a new process group with the process group ID set
to its process ID.
- uint32_t runmask
- (QNX Neutrino Core OS 6.3.2 or later)
If you specify SPAWN_EXPLICIT_CPU in the flags
member, the child process's runmask and inherit mask are set to the
value of this member.
For more information, see the
Multicore Processing
chapter of the QNX Neutrino Programmer's Guide.
- sigset_t sigmask
- The child process's signal mask if you specify
SPAWN_SETSIGMASK in the flags member.
- sigset_t sigdefault
- The child process's set of defaulted signals if you specify
SPAWN_SETSIGDEF in the flags member.
- sigset_t sigignore
- The child process's set of ignored signals if you specify
SPAWN_SETSIGIGN in the flags member.
- uint32_t stack_max
- The maximum stack size for the child process, if you set
SPAWN_SETSTACKMAX in the flags member.
- int32_t policy
- The scheduling policy for the child process, if you set
SPAWN_EXPLICIT_SCHED in the flags member.
The policy must be one of the following:
- SCHED_FIFO — a fixed-priority scheduler in which
the highest priority ready thread runs until it blocks or is preempted
by a higher priority thread.
- SCHED_RR — similar to SCHED_FIFO,
except that threads at the same priority level timeslice (round robin)
every 4 × the clock period (see
ClockPeriod()).
- SCHED_OTHER — currently the same as
SCHED_RR.
- SCHED_SPORADIC — sporadic scheduling.
- struct sched_param param
- Scheduling parameters for the child process, if you set
SPAWN_EXPLICIT_SCHED in the flags member.
For more information, see the documentation for
sched_param.
Note:
In order to create a thread whose priority is above the maximum permitted for unprivileged processes,
your process must have the
PROCMGR_AID_PRIORITY ability enabled.
For more information, see
procmgr_ability().