1POSIX_SPAWN(3P) POSIX Programmer's Manual POSIX_SPAWN(3P)
2
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
13 posix_spawn, posix_spawnp — spawn a process (ADVANCED REALTIME)
14
16 #include <spawn.h>
17 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
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 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 int main(int argc, char *argv[]);
37 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 extern char **environ;
43 shall be initialized as a pointer to an array of character pointers to
45 the environment strings.
46 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 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 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 The path argument to posix_spawn() is a pathname that identifies the
66 new process image file to execute.
67 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 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 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 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 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 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 4. Any file descriptor that has its FD_CLOEXEC flag set (see fcntl())
106 shall be closed.
107 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 The posix_spawnattr_t spawn attributes object type is defined in
119 <spawn.h>. It shall contain at least the attributes defined below.
120 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 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 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 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 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 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 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 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 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 Signals set to be caught by the calling process shall be set to the
183 default action in the child process.
184 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 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 If the value of the attrp pointer is NULL, then the default values are
201 used.
202 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 It is implementation-defined whether the fork handlers are run when
211 posix_spawn() or posix_spawnp() is called.
212
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
224 These functions may fail if:
225 EINVAL The value specified by file_actions or attrp is invalid.
227 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 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 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 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 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 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 The following sections are informative.
271
273 None.
274
276 These functions are part of the Spawn option and need not be provided
277 on all implementations.
278 See also the APPLICATION USAGE section for exec.
280
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 * Swapping is generally too slow for a realtime environment.
288 * Dynamic address translation is not available everywhere that POSIX
290 might be useful.
291 * Processes are too useful to simply option out of POSIX whenever it
293 must run without address translation or other MMU services.
294 Thus, POSIX needs process creation and file execution primitives that
296 can be efficiently implemented without address translation or other MMU
297 services.
298 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 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 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 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 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 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 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 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 Requirements
372 The requirements for posix_spawn() and posix_spawnp() are:
373 * They must be implementable without an MMU or unusual hardware.
375 * They must be compatible with existing POSIX standards.
377 Additional goals are:
379 * They should be efficiently implementable.
381 * They should be able to replace at least 50% of typical executions
383 of fork().
384 * A system with posix_spawn() and posix_spawnp() and without fork()
386 should be useful, at least for realtime applications.
387 * A system with fork() and the exec family should be able to imple‐
389 ment posix_spawn() and posix_spawnp() as library routines.
390 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 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 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 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 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 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 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 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 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 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 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 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
519 None.
520
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 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 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 .
550IEEE/The Open Group 2013 POSIX_SPAWN(3P)