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

NAME

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

SYNOPSIS

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

DESCRIPTION

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

RETURN VALUE

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

ERRORS

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

EXAMPLES

275       None.
276

APPLICATION USAGE

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

RATIONALE

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

FUTURE DIRECTIONS

521       None.
522

SEE ALSO

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