1POSIX_SPAWN(3P)            POSIX Programmer's Manual           POSIX_SPAWN(3P)
2
3
4

PROLOG

6       This  manual  page is part of the POSIX Programmer's Manual.  The Linux
7       implementation of this interface may differ (consult the  corresponding
8       Linux  manual page for details of Linux behavior), or the interface may
9       not be implemented on Linux.
10
11

NAME

13       posix_spawn, posix_spawnp — spawn a process (ADVANCED REALTIME)
14

SYNOPSIS

16       #include <spawn.h>
17
18       int posix_spawn(pid_t *restrict pid, const char *restrict path,
19           const posix_spawn_file_actions_t *file_actions,
20           const posix_spawnattr_t *restrict attrp,
21           char *const argv[restrict], char *const envp[restrict]);
22       int posix_spawnp(pid_t *restrict pid, const char *restrict file,
23           const posix_spawn_file_actions_t *file_actions,
24           const posix_spawnattr_t *restrict attrp,
25           char *const argv[restrict], char *const envp[restrict]);
26

DESCRIPTION

28       The posix_spawn() and  posix_spawnp()  functions  shall  create  a  new
29       process  (child  process)  from  the  specified  process image. The new
30       process image shall be  constructed  from  a  regular  executable  file
31       called the new process image file.
32
33       When  a  C  program is executed as the result of this call, it shall be
34       entered as a C-language function call as follows:
35
36           int main(int argc, char *argv[]);
37
38       where argc is the argument count and argv  is  an  array  of  character
39       pointers  to the arguments themselves. In addition, the following vari‐
40       able:
41
42           extern char **environ;
43
44       shall be initialized as a pointer to an array of character pointers  to
45       the environment strings.
46
47       The  argument argv is an array of character pointers to null-terminated
48       strings. The last member of this array shall be a null pointer  and  is
49       not counted in argc.  These strings constitute the argument list avail‐
50       able to the new process image. The value in argv[0] should point  to  a
51       filename string that is associated with the process image being started
52       by the posix_spawn() or posix_spawnp() function.
53
54       The argument envp is an array of character pointers to  null-terminated
55       strings.  These  strings constitute the environment for the new process
56       image. The environment array is terminated by a null pointer.
57
58       The number of bytes available for the combined argument and environment
59       lists  of  the  child  process  is {ARG_MAX}.  The implementation shall
60       specify in the system documentation (see the Base Definitions volume of
61       POSIX.1‐2008,  Chapter  2, Conformance) whether any list overhead, such
62       as length words, null terminators, pointers,  or  alignment  bytes,  is
63       included in this total.
64
65       The  path  argument  to posix_spawn() is a pathname that identifies the
66       new process image file to execute.
67
68       The file parameter to posix_spawnp() shall be used to construct a path‐
69       name  that identifies the new process image file. If the file parameter
70       contains a <slash> character, the file parameter shall be used  as  the
71       pathname for the new process image file. Otherwise, the path prefix for
72       this file shall be obtained by a search of the  directories  passed  as
73       the  environment  variable  PATH  (see  the  Base Definitions volume of
74       POSIX.1‐2008, Chapter 8, Environment Variables).  If  this  environment
75       variable  is not defined, the results of the search are implementation-
76       defined.
77
78       If file_actions is a null pointer, then file descriptors  open  in  the
79       calling  process  shall  remain  open  in the child process, except for
80       those whose close-on-exec flag FD_CLOEXEC is set  (see  fcntl()).   For
81       those  file  descriptors that remain open, all attributes of the corre‐
82       sponding open file descriptions, including file  locks  (see  fcntl()),
83       shall remain unchanged.
84
85       If  file_actions  is  not  NULL,  then the file descriptors open in the
86       child process shall be those open in the calling process as modified by
87       the  spawn  file  actions  object  pointed  to  by file_actions and the
88       FD_CLOEXEC flag of each remaining open file descriptor after the  spawn
89       file actions have been processed. The effective order of processing the
90       spawn file actions shall be:
91
92        1. The set of open file descriptors for the child process  shall  ini‐
93           tially  be  the  same  set  as is open for the calling process. All
94           attributes of the corresponding open file  descriptions,  including
95           file locks (see fcntl()), shall remain unchanged.
96
97        2. The signal mask, signal default actions, and the effective user and
98           group IDs for the child process shall be changed  as  specified  in
99           the attributes object referenced by attrp.
100
101        3. The  file  actions specified by the spawn file actions object shall
102           be performed in the order in which they were  added  to  the  spawn
103           file actions object.
104
105        4. Any  file descriptor that has its FD_CLOEXEC flag set (see fcntl())
106           shall be closed.
107
108       If file descriptor 0, 1, or 2 would otherwise  be  closed  in  the  new
109       process  image  created by posix_spawn() or posix_spawnp(), implementa‐
110       tions may open an unspecified file for the file descriptor in  the  new
111       process  image.  If  a  standard utility or a conforming application is
112       executed with file descriptor 0 not  open  for  reading  or  with  file
113       descriptor  1  or  2 not open for writing, the environment in which the
114       utility or application is executed shall be deemed non-conforming,  and
115       consequently  the  utility or application might not behave as described
116       in this standard.
117
118       The posix_spawnattr_t  spawn  attributes  object  type  is  defined  in
119       <spawn.h>.  It shall contain at least the attributes defined below.
120
121       If  the  POSIX_SPAWN_SETPGROUP flag is set in the spawn-flags attribute
122       of the object referenced by attrp, and the  spawn-pgroup  attribute  of
123       the same object is non-zero, then the child's process group shall be as
124       specified in the spawn-pgroup attribute of  the  object  referenced  by
125       attrp.
126
127       As  a  special  case,  if  the POSIX_SPAWN_SETPGROUP flag is set in the
128       spawn-flags attribute of the object referenced by attrp, and the spawn-
129       pgroup  attribute  of  the  same  object is set to zero, then the child
130       shall be in a new process group with a process group ID  equal  to  its
131       process ID.
132
133       If  the  POSIX_SPAWN_SETPGROUP  flag  is  not  set  in  the spawn-flags
134       attribute of the object referenced by  attrp,  the  new  child  process
135       shall inherit the parent's process group.
136
137       If  the  POSIX_SPAWN_SETSCHEDPARAM  flag  is  set  in  the  spawn-flags
138       attribute of the object referenced by attrp, but  POSIX_SPAWN_SETSCHED‐
139       ULER  is not set, the new process image shall initially have the sched‐
140       uling policy of the calling  process  with  the  scheduling  parameters
141       specified in the spawn-schedparam attribute of the object referenced by
142       attrp.
143
144       If  the  POSIX_SPAWN_SETSCHEDULER  flag  is  set  in  the   spawn-flags
145       attribute  of the object referenced by attrp (regardless of the setting
146       of the POSIX_SPAWN_SETSCHEDPARAM flag), the  new  process  image  shall
147       initially have the scheduling policy specified in the spawn-schedpolicy
148       attribute of the object referenced by attrp and the scheduling  parame‐
149       ters specified in the spawn-schedparam attribute of the same object.
150
151       The  POSIX_SPAWN_RESETIDS  flag  in  the  spawn-flags  attribute of the
152       object referenced by attrp governs the effective user ID of  the  child
153       process.  If  this flag is not set, the child process shall inherit the
154       effective user ID of the parent process.  If  this  flag  is  set,  the
155       effective  user  ID of the child process shall be reset to the parent's
156       real user ID. In either case, if the set-user-ID mode bit  of  the  new
157       process  image  file is set, the effective user ID of the child process
158       shall become that file's owner ID before the new process  image  begins
159       execution.
160
161       The  POSIX_SPAWN_RESETIDS  flag  in  the  spawn-flags  attribute of the
162       object referenced by attrp also governs the effective group ID  of  the
163       child process. If this flag is not set, the child process shall inherit
164       the effective group ID of the parent process. If this flag is set,  the
165       effective  group ID of the child process shall be reset to the parent's
166       real group ID. In either case, if the set-group-ID mode bit of the  new
167       process  image file is set, the effective group ID of the child process
168       shall become that file's group ID before the new process  image  begins
169       execution.
170
171       If  the POSIX_SPAWN_SETSIGMASK flag is set in the spawn-flags attribute
172       of the object referenced by attrp, the child  process  shall  initially
173       have  the  signal  mask specified in the spawn-sigmask attribute of the
174       object referenced by attrp.
175
176       If the POSIX_SPAWN_SETSIGDEF flag is set in the  spawn-flags  attribute
177       of  the object referenced by attrp, the signals specified in the spawn-
178       sigdefault attribute of the same object shall be set to  their  default
179       actions  in the child process. Signals set to the default action in the
180       parent process shall be set to the default action in the child process.
181
182       Signals set to be caught by the calling process shall  be  set  to  the
183       default action in the child process.
184
185       Except  for  SIGCHLD,  signals set to be ignored by the calling process
186       image shall be set to be ignored by the child process, unless otherwise
187       specified  by  the  POSIX_SPAWN_SETSIGDEF  flag being set in the spawn-
188       flags attribute of the object referenced by attrp and the signals being
189       indicated in the spawn-sigdefault attribute of the object referenced by
190       attrp.
191
192       If the SIGCHLD signal is set to be ignored by the calling  process,  it
193       is  unspecified  whether  the SIGCHLD signal is set to be ignored or to
194       the default action in the child process, unless otherwise specified  by
195       the  POSIX_SPAWN_SETSIGDEF  flag being set in the spawn_flags attribute
196       of the object referenced by attrp and the SIGCHLD  signal  being  indi‐
197       cated  in  the  spawn_sigdefault  attribute of the object referenced by
198       attrp.
199
200       If the value of the attrp pointer is NULL, then the default values  are
201       used.
202
203       All  process  attributes, other than those influenced by the attributes
204       set in the object referenced by attrp as specified above or by the file
205       descriptor manipulations specified in file_actions, shall appear in the
206       new process image as though fork() had been called to  create  a  child
207       process  and  then  a  member  of the exec family of functions had been
208       called by the child process to execute the new process image.
209
210       It is implementation-defined whether the fork  handlers  are  run  when
211       posix_spawn() or posix_spawnp() is called.
212

RETURN VALUE

214       Upon  successful  completion,  posix_spawn()  and  posix_spawnp() shall
215       return the process ID of the child process to the  parent  process,  in
216       the  variable  pointed  to by a non-NULL pid argument, and shall return
217       zero as the function return value.  Otherwise, no child  process  shall
218       be created, the value stored into the variable pointed to by a non-NULL
219       pid is unspecified, and an error number shall be returned as the  func‐
220       tion  return value to indicate the error. If the pid argument is a null
221       pointer, the process ID of the child is not returned to the caller.
222

ERRORS

224       These functions may fail if:
225
226       EINVAL The value specified by file_actions or attrp is invalid.
227
228       If this error occurs after the  calling  process  successfully  returns
229       from  the  posix_spawn()  or posix_spawnp() function, the child process
230       may exit with exit status 127.
231
232       If posix_spawn() or posix_spawnp() fail for any  of  the  reasons  that
233       would  cause  fork() or one of the exec family of functions to fail, an
234       error value shall be returned as described by fork() and exec,  respec‐
235       tively  (or, if the error occurs after the calling process successfully
236       returns, the child process shall exit with exit status 127).
237
238       If POSIX_SPAWN_SETPGROUP is set in the  spawn-flags  attribute  of  the
239       object  referenced  by attrp, and posix_spawn() or posix_spawnp() fails
240       while changing the child's process  group,  an  error  value  shall  be
241       returned  as  described by setpgid() (or, if the error occurs after the
242       calling process successfully returns, the child process shall exit with
243       exit status 127).
244
245       If POSIX_SPAWN_SETSCHEDPARAM is set and POSIX_SPAWN_SETSCHEDULER is not
246       set in the spawn-flags attribute of the  object  referenced  by  attrp,
247       then  if  posix_spawn()  or posix_spawnp() fails for any of the reasons
248       that would cause sched_setparam() to fail,  an  error  value  shall  be
249       returned  as  described  by  sched_setparam()  (or, if the error occurs
250       after the calling process successfully returns, the child process shall
251       exit with exit status 127).
252
253       If  POSIX_SPAWN_SETSCHEDULER is set in the spawn-flags attribute of the
254       object referenced by attrp,  and  if  posix_spawn()  or  posix_spawnp()
255       fails  for  any of the reasons that would cause sched_setscheduler() to
256       fail, an error value shall be returned as described by  sched_setsched‐
257       uler()  (or, if the error occurs after the calling process successfully
258       returns, the child process shall exit with exit status 127).
259
260       If the file_actions argument is not  NULL,  and  specifies  any  close,
261       dup2,  or  open  actions  to  be  performed,  and  if  posix_spawn() or
262       posix_spawnp() fails for any of the reasons that would  cause  close(),
263       dup2(),  or  open()  to  fail,  an  error  value  shall  be returned as
264       described by close(), dup2(), and  open(),  respectively  (or,  if  the
265       error  occurs after the calling process successfully returns, the child
266       process shall exit with exit status 127). An open file action  may,  by
267       itself,  result in any of the errors described by close() or dup2(), in
268       addition to those described by open().
269
270       The following sections are informative.
271

EXAMPLES

273       None.
274

APPLICATION USAGE

276       These functions are part of the Spawn option and need not  be  provided
277       on all implementations.
278
279       See also the APPLICATION USAGE section for exec.
280

RATIONALE

282       The  posix_spawn()  function and its close relation posix_spawnp() have
283       been introduced to overcome the following perceived  difficulties  with
284       fork():  the  fork()  function  is difficult or impossible to implement
285       without swapping or dynamic address translation.
286
287        *  Swapping is generally too slow for a realtime environment.
288
289        *  Dynamic address translation is not available everywhere that  POSIX
290           might be useful.
291
292        *  Processes  are too useful to simply option out of POSIX whenever it
293           must run without address translation or other MMU services.
294
295       Thus, POSIX needs process creation and file execution  primitives  that
296       can be efficiently implemented without address translation or other MMU
297       services.
298
299       The posix_spawn() function is implementable as a library  routine,  but
300       both  posix_spawn()  and  posix_spawnp()  are designed as kernel opera‐
301       tions. Also, although they may be an  efficient  replacement  for  many
302       fork()/exec  pairs,  their  goal  is to provide useful process creation
303       primitives for systems that have difficulty with fork(), not to provide
304       drop-in replacements for fork()/exec.
305
306       This  view  of  the role of posix_spawn() and posix_spawnp() influenced
307       the design of their API. It does not attempt to provide the full  func‐
308       tionality  of  fork()/exec in which arbitrary user-specified operations
309       of any sort are permitted between the creation of the child process and
310       the execution of the new process image; any attempt to reach that level
311       would need to provide a programming language  as  parameters.  Instead,
312       posix_spawn()  and  posix_spawnp() are process creation primitives like
313       the Start_Process and Start_Process_Search Ada language bindings  pack‐
314       age POSIX_Process_Primitives and also like those in many operating sys‐
315       tems that are not UNIX systems, but with some POSIX-specific additions.
316
317       To achieve its coverage goals, posix_spawn()  and  posix_spawnp()  have
318       control  of  six  types of inheritance: file descriptors, process group
319       ID, user and group ID, signal mask, scheduling, and whether each signal
320       ignored  in the parent will remain ignored in the child, or be reset to
321       its default action in the child.
322
323       Control of file descriptors is required to allow an independently writ‐
324       ten  child process image to access data streams opened by and even gen‐
325       erated or read by the parent process without being  specifically  coded
326       to  know  which parent files and file descriptors are to be used.  Con‐
327       trol of the process group ID is required to control how the job control
328       of the child process relates to that of the parent.
329
330       Control  of the signal mask and signal defaulting is sufficient to sup‐
331       port the implementation of system().  Although support for system()  is
332       not  explicitly  one of the goals for posix_spawn() and posix_spawnp(),
333       it is covered under the ``at least 50%'' coverage goal.
334
335       The intention is that the normal  file  descriptor  inheritance  across
336       fork(),  the subsequent effect of the specified spawn file actions, and
337       the normal file descriptor inheritance across one of the exec family of
338       functions  should  fully specify open file inheritance. The implementa‐
339       tion need make no decisions regarding the set of open file  descriptors
340       when  the  child process image begins execution, those decisions having
341       already been made by the caller and expressed as the set of  open  file
342       descriptors  and their FD_CLOEXEC flags at the time of the call and the
343       spawn file actions object specified in the call. We have  been  assured
344       that  in  cases  where the POSIX Start_Process Ada primitives have been
345       implemented in a library, this method of  controlling  file  descriptor
346       inheritance may be implemented very easily.
347
348       We can identify several problems with posix_spawn() and posix_spawnp(),
349       but there does not appear to be a solution that introduces fewer  prob‐
350       lems.  Environment modification for child process attributes not speci‐
351       fiable via the attrp or file_actions arguments must be done in the par‐
352       ent  process, and since the parent generally wants to save its context,
353       it is more costly than similar functionality with fork()/exec.   It  is
354       also  complicated to modify the environment of a multi-threaded process
355       temporarily, since all threads must agree when it is safe for the envi‐
356       ronment  to be changed. However, this cost is only borne by those invo‐
357       cations of posix_spawn() and posix_spawnp()  that  use  the  additional
358       functionality.  Since  extensive  modifications are not the usual case,
359       and are particularly unlikely in time-critical code,  keeping  much  of
360       the  environment  control  out  of  posix_spawn() and posix_spawnp() is
361       appropriate design.
362
363       The posix_spawn() and posix_spawnp() functions  do  not  have  all  the
364       power of fork()/exec.  This is to be expected. The fork() function is a
365       wonderfully powerful operation. We do not expect to duplicate its func‐
366       tionality  in a simple, fast function with no special hardware require‐
367       ments. It is worth noting that  posix_spawn()  and  posix_spawnp()  are
368       very  similar to the process creation operations on many operating sys‐
369       tems that are not UNIX systems.
370
371   Requirements
372       The requirements for posix_spawn() and posix_spawnp() are:
373
374        *  They must be implementable without an MMU or unusual hardware.
375
376        *  They must be compatible with existing POSIX standards.
377
378       Additional goals are:
379
380        *  They should be efficiently implementable.
381
382        *  They should be able to replace at least 50% of  typical  executions
383           of fork().
384
385        *  A  system  with posix_spawn() and posix_spawnp() and without fork()
386           should be useful, at least for realtime applications.
387
388        *  A system with fork() and the exec family should be able  to  imple‐
389           ment posix_spawn() and posix_spawnp() as library routines.
390
391   Two-Syntax
392       POSIX  exec  has  several calling sequences with approximately the same
393       functionality. These appear  to  be  required  for  compatibility  with
394       existing  practice.  Since the existing practice for the posix_spawn*()
395       functions is otherwise substantially unlike POSIX, we  feel  that  sim‐
396       plicity  outweighs  compatibility. There are, therefore, only two names
397       for the posix_spawn*() functions.
398
399       The  parameter  list  does  not  differ   between   posix_spawn()   and
400       posix_spawnp();  posix_spawnp()  interprets  the  second parameter more
401       elaborately than posix_spawn().
402
403   Compatibility with POSIX.5 (Ada)
404       The  Start_Process  and  Start_Process_Search   procedures   from   the
405       POSIX_Process_Primitives  package  from  the  Ada  language  binding to
406       POSIX.1 encapsulate fork() and exec functionality in a  manner  similar
407       to  that  of  posix_spawn() and posix_spawnp().  Originally, in keeping
408       with our simplicity goal, the standard developers had limited the capa‐
409       bilities  of  posix_spawn() and posix_spawnp() to a subset of the capa‐
410       bilities of Start_Process and Start_Process_Search; certain non-default
411       capabilities  were  not supported. However, based on suggestions by the
412       ballot group to improve file descriptor mapping or drop it, and on  the
413       advice  of  an Ada Language Bindings working group member, the standard
414       developers decided that posix_spawn() and posix_spawnp() should be suf‐
415       ficiently powerful to implement Start_Process and Start_Process_Search.
416       The rationale is that if the Ada language binding to such  a  primitive
417       had already been approved as an IEEE standard, there can be little jus‐
418       tification for not approving the functionally-equivalent parts of  a  C
419       binding.  The  only  three  capabilities  provided by posix_spawn() and
420       posix_spawnp()   that   are   not   provided   by   Start_Process   and
421       Start_Process_Search  are  optionally  specifying  the  child's process
422       group ID, the set of signals to be reset to default signal handling  in
423       the child process, and the child's scheduling policy and parameters.
424
425       For  the  Ada language binding for Start_Process to be implemented with
426       posix_spawn(), that binding would need to explicitly pass an empty sig‐
427       nal  mask  and  the  parent's environment to posix_spawn() whenever the
428       caller of Start_Process  allowed  these  arguments  to  default,  since
429       posix_spawn()   does   not   provide  such  defaults.  The  ability  of
430       Start_Process to mask user-specified signals during  its  execution  is
431       functionally  unique to the Ada language binding and must be dealt with
432       in the binding separately from the call to posix_spawn().
433
434   Process Group
435       The process group inheritance field can  be  used  to  join  the  child
436       process with an existing process group. By assigning a value of zero to
437       the spawn-pgroup attribute of  the  object  referenced  by  attrp,  the
438       setpgid()  mechanism  will  place  the  child  process in a new process
439       group.
440
441   Threads
442       Without the posix_spawn() and posix_spawnp() functions, systems without
443       address  translation  can  still  use threads to give an abstraction of
444       concurrency. In many cases, thread creation suffices,  but  it  is  not
445       always  a  good  substitute. The posix_spawn() and posix_spawnp() func‐
446       tions are considerably ``heavier'' than thread creation. Processes have
447       several  important attributes that threads do not. Even without address
448       translation, a process may have base-and-bound memory protection.  Each
449       process  has  a  process  environment including security attributes and
450       file  capabilities,  and  powerful  scheduling  attributes.   Processes
451       abstract  the behavior of non-uniform-memory-architecture multi-proces‐
452       sors better than threads, and they  are  more  convenient  to  use  for
453       activities that are not closely linked.
454
455       The  posix_spawn()  and  posix_spawnp() functions may not bring support
456       for multiple processes to every configuration. Process creation is  not
457       the only piece of operating system support required to support multiple
458       processes. The total cost of support  for  multiple  processes  may  be
459       quite  high in some circumstances. Existing practice shows that support
460       for multiple processes is uncommon and threads are common among  ``tiny
461       kernels''.   There  should, therefore, probably continue to be AEPs for
462       operating systems with only one process.
463
464   Asynchronous Error Notification
465       A library implementation of posix_spawn() or posix_spawnp() may not  be
466       able  to  detect all possible errors before it forks the child process.
467       POSIX.1‐2008 provides for an error indication  returned  from  a  child
468       process which could not successfully complete the spawn operation via a
469       special exit status which  may  be  detected  using  the  status  value
470       returned by wait(), waitid(), and waitpid().
471
472       The stat_val interface and the macros used to interpret it are not well
473       suited to the purpose of returning API errors, but they  are  the  only
474       path available to a library implementation. Thus, an implementation may
475       cause the child process to exit with exit  status  127  for  any  error
476       detected   during   the   spawn  process  after  the  posix_spawn()  or
477       posix_spawnp() function has successfully returned.
478
479       The standard developers had proposed using  two  additional  macros  to
480       interpret  stat_val.   The  first,  WIFSPAWNFAIL, would have detected a
481       status that indicated  that  the  child  exited  because  of  an  error
482       detected  during  the posix_spawn() or posix_spawnp() operations rather
483       than during actual execution of the child process  image;  the  second,
484       WSPAWNERRNO, would have extracted the error value if WIFSPAWNFAIL indi‐
485       cated a failure. Unfortunately, the ballot group strongly opposed  this
486       because  it  would  make  a  library implementation of posix_spawn() or
487       posix_spawnp() dependent on kernel modifications  to  waitpid()  to  be
488       able to embed special information in stat_val to indicate a spawn fail‐
489       ure.
490
491       The 8 bits  of  child  process  exit  status  that  are  guaranteed  by
492       POSIX.1‐2008  to be accessible to the waiting parent process are insuf‐
493       ficient to disambiguate a spawn error from any other kind of error that
494       may  be  returned  by  an arbitrary process image. No other bits of the
495       exit status are required to be visible in  stat_val,  so  these  macros
496       could  not  be strictly implemented at the library level.  Reserving an
497       exit status of 127 for such spawn errors is consistent with the use  of
498       this  value  by system() and popen() to signal failures in these opera‐
499       tions that occur after the function has returned but before a shell  is
500       able to execute. The exit status of 127 does not uniquely identify this
501       class of error, nor does it provide any  detailed  information  on  the
502       nature   of   the   failure.  Note  that  a  kernel  implementation  of
503       posix_spawn() or posix_spawnp() is permitted (and encouraged) to return
504       any  possible error as the function value, thus providing more detailed
505       failure information to the parent process.
506
507       Thus,  no  special  macros  are  available  to   isolate   asynchronous
508       posix_spawn() or posix_spawnp() errors. Instead, errors detected by the
509       posix_spawn() or posix_spawnp() operations in the context of the  child
510       process  before  the new process image executes are reported by setting
511       the child's exit status to 127.  The calling process may use the WIFEX‐
512       ITED  and  WEXITSTATUS  macros  on the stat_val stored by the wait() or
513       waitpid() functions to detect spawn failures to the extent  that  other
514       status  values  with which the child process image may exit (before the
515       parent can conclusively determine that  the  child  process  image  has
516       begun execution) are distinct from exit status 127.
517

FUTURE DIRECTIONS

519       None.
520

SEE ALSO

522       alarm(), chmod(), close(), dup(), exec, exit(), fcntl(), fork(),
523       fstatat(), kill(), open(), posix_spawn_file_actions_addclose(),
524       posix_spawn_file_actions_adddup2(), posix_spawn_file_actions_destroy(),
525       posix_spawnattr_destroy(), posix_spawnattr_getsigdefault(), posix_spaw‐
526       nattr_getflags(), posix_spawnattr_getpgroup(), posix_spaw‐
527       nattr_getschedparam(), posix_spawnattr_getschedpolicy(), posix_spaw‐
528       nattr_getsigmask(), sched_setparam(), sched_setscheduler(), setpgid(),
529       setuid(), times(), wait(), waitid()
530
531       The Base Definitions volume of  POSIX.1‐2008,  Chapter  8,  Environment
532       Variables, <spawn.h>
533
535       Portions  of  this text are reprinted and reproduced in electronic form
536       from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
537       --  Portable  Operating  System  Interface (POSIX), The Open Group Base
538       Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
539       cal  and  Electronics  Engineers,  Inc  and  The  Open Group.  (This is
540       POSIX.1-2008 with the 2013 Technical Corrigendum  1  applied.)  In  the
541       event of any discrepancy between this version and the original IEEE and
542       The Open Group Standard, the original IEEE and The Open Group  Standard
543       is  the  referee document. The original Standard can be obtained online
544       at http://www.unix.org/online.html .
545
546       Any typographical or formatting errors that appear  in  this  page  are
547       most likely to have been introduced during the conversion of the source
548       files to man page format. To report such errors,  see  https://www.ker
549       nel.org/doc/man-pages/reporting_bugs.html .
550
551
552
553IEEE/The Open Group                  2013                      POSIX_SPAWN(3P)
Impressum