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
12 posix_spawn, posix_spawnp - spawn a process (ADVANCED REALTIME)
13
15 #include <spawn.h>
16 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
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[]);
38 where argc is the argument count and argv is an array of character
40 pointers to the arguments themselves. In addition, the following vari‐
41 able:
42 extern char **environ;
45 shall be initialized as a pointer to an array of character pointers to
47 the environment strings.
48 The argument argv is an array of character pointers to null-terminated
50 strings. The last member of this array shall be a null pointer and is
51 not counted in argc. These strings constitute the argument list avail‐
52 able to the new process image. The value in argv[0] should point to a
53 filename that is associated with the process image being started by the
54 posix_spawn() or posix_spawnp() function.
55 The argument envp is an array of character pointers to null-terminated
57 strings. These strings constitute the environment for the new process
58 image. The environment array is terminated by a null pointer.
59 The number of bytes available for the child process' combined argument
61 and environment lists is {ARG_MAX}. The implementation shall specify in
62 the system documentation (see the Base Definitions volume of
63 IEEE Std 1003.1-2001, Chapter 2, Conformance) whether any list over‐
64 head, such as length words, null terminators, pointers, or alignment
65 bytes, is included in this total.
66 The path argument to posix_spawn() is a pathname that identifies the
68 new process image file to execute.
69 The file parameter to posix_spawnp() shall be used to construct a path‐
71 name that identifies the new process image file. If the file parameter
72 contains a slash character, the file parameter shall be used as the
73 pathname for the new process image file. Otherwise, the path prefix for
74 this file shall be obtained by a search of the directories passed as
75 the environment variable PATH (see the Base Definitions volume of
76 IEEE Std 1003.1-2001, Chapter 8, Environment Variables). If this envi‐
77 ronment variable is not defined, the results of the search are imple‐
78 mentation-defined.
79 If file_actions is a null pointer, then file descriptors open in the
81 calling process shall remain open in the child process, except for
82 those whose close-on- exec flag FD_CLOEXEC is set (see fcntl()). For
83 those file descriptors that remain open, all attributes of the corre‐
84 sponding open file descriptions, including file locks (see fcntl()),
85 shall remain unchanged.
86 If file_actions is not NULL, then the file descriptors open in the
88 child process shall be those open in the calling process as modified by
89 the spawn file actions object pointed to by file_actions and the
90 FD_CLOEXEC flag of each remaining open file descriptor after the spawn
91 file actions have been processed. The effective order of processing
92 the spawn file actions shall be:
93 1. The set of open file descriptors for the child process shall ini‐
95 tially be the same set as is open for the calling process. All
96 attributes of the corresponding open file descriptions, including
97 file locks (see fcntl()), shall remain unchanged.
98 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 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 4. Any file descriptor that has its FD_CLOEXEC flag set (see fcntl() )
108 shall be closed.
109 The posix_spawnattr_t spawn attributes object type is defined in
111 <spawn.h>. It shall contain at least the attributes defined below.
112 If the POSIX_SPAWN_SETPGROUP flag is set in the spawn-flags attribute
114 of the object referenced by attrp, and the spawn-pgroup attribute of
115 the same object is non-zero, then the child's process group shall be as
116 specified in the spawn-pgroup attribute of the object referenced by
117 attrp.
118 As a special case, if the POSIX_SPAWN_SETPGROUP flag is set in the
120 spawn-flags attribute of the object referenced by attrp, and the spawn-
121 pgroup attribute of the same object is set to zero, then the child
122 shall be in a new process group with a process group ID equal to its
123 process ID.
124 If the POSIX_SPAWN_SETPGROUP flag is not set in the spawn-flags
126 attribute of the object referenced by attrp, the new child process
127 shall inherit the parent's process group.
128 If the POSIX_SPAWN_SETSCHEDPARAM flag is set in the spawn-flags
130 attribute of the object referenced by attrp, but POSIX_SPAWN_SETSCHED‐
131 ULER is not set, the new process image shall initially have the sched‐
132 uling policy of the calling process with the scheduling parameters
133 specified in the spawn-schedparam attribute of the object referenced by
134 attrp.
135 If the POSIX_SPAWN_SETSCHEDULER flag is set in the spawn-flags
137 attribute of the object referenced by attrp (regardless of the setting
138 of the POSIX_SPAWN_SETSCHEDPARAM flag), the new process image shall
139 initially have the scheduling policy specified in the spawn-schedpolicy
140 attribute of the object referenced by attrp and the scheduling parame‐
141 ters specified in the spawn-schedparam attribute of the same object.
142 The POSIX_SPAWN_RESETIDS flag in the spawn-flags attribute of the
144 object referenced by attrp governs the effective user ID of the child
145 process. If this flag is not set, the child process shall inherit the
146 parent process' effective user ID. If this flag is set, the child
147 process' effective user ID shall be reset to the parent's real user ID.
148 In either case, if the set-user-ID mode bit of the new process image
149 file is set, the effective user ID of the child process shall become
150 that file's owner ID before the new process image begins execution.
151 The POSIX_SPAWN_RESETIDS flag in the spawn-flags attribute of the
153 object referenced by attrp also governs the effective group ID of the
154 child process. If this flag is not set, the child process shall inherit
155 the parent process' effective group ID. If this flag is set, the child
156 process' effective group ID shall be reset to the parent's real group
157 ID. In either case, if the set-group-ID mode bit of the new process
158 image file is set, the effective group ID of the child process shall
159 become that file's group ID before the new process image begins execu‐
160 tion.
161 If the POSIX_SPAWN_SETSIGMASK flag is set in the spawn-flags attribute
163 of the object referenced by attrp, the child process shall initially
164 have the signal mask specified in the spawn-sigmask attribute of the
165 object referenced by attrp.
166 If the POSIX_SPAWN_SETSIGDEF flag is set in the spawn-flags attribute
168 of the object referenced by attrp, the signals specified in the spawn-
169 sigdefault attribute of the same object shall be set to their default
170 actions in the child process. Signals set to the default action in the
171 parent process shall be set to the default action in the child process.
172 Signals set to be caught by the calling process shall be set to the
174 default action in the child process.
175 Except for SIGCHLD, signals set to be ignored by the calling process
177 image shall be set to be ignored by the child process, unless otherwise
178 specified by the POSIX_SPAWN_SETSIGDEF flag being set in the spawn-
179 flags attribute of the object referenced by attrp and the signals being
180 indicated in the spawn-sigdefault attribute of the object referenced by
181 attrp.
182 If the SIGCHLD signal is set to be ignored by the calling process, it
184 is unspecified whether the SIGCHLD signal is set to be ignored or to
185 the default action in the child process, unless otherwise specified by
186 the POSIX_SPAWN_SETSIGDEF flag being set in the spawn_flags attribute
187 of the object referenced by attrp and the SIGCHLD signal being indi‐
188 cated in the spawn_sigdefault attribute of the object referenced by
189 attrp.
190 If the value of the attrp pointer is NULL, then the default values are
192 used.
193 All process attributes, other than those influenced by the attributes
195 set in the object referenced by attrp as specified above or by the file
196 descriptor manipulations specified in file_actions, shall appear in the
197 new process image as though fork() had been called to create a child
198 process and then a member of the exec family of functions had been
199 called by the child process to execute the new process image.
200 It is implementation-defined whether the fork handlers are run when
202 posix_spawn() or posix_spawnp() is called.
203
205 Upon successful completion, posix_spawn() and posix_spawnp() shall
206 return the process ID of the child process to the parent process, in
207 the variable pointed to by a non-NULL pid argument, and shall return
208 zero as the function return value. Otherwise, no child process shall be
209 created, the value stored into the variable pointed to by a non-NULL
210 pid is unspecified, and an error number shall be returned as the func‐
211 tion return value to indicate the error. If the pid argument is a null
212 pointer, the process ID of the child is not returned to the caller.
213
215 The posix_spawn() and posix_spawnp() functions may fail if:
216 EINVAL The value specified by file_actions or attrp is invalid.
218 If this error occurs after the calling process successfully returns
221 from the posix_spawn() or posix_spawnp() function, the child process
222 may exit with exit status 127.
223 If posix_spawn() or posix_spawnp() fail for any of the reasons that
225 would cause fork() or one of the exec family of functions to fail, an
226 error value shall be returned as described by fork() and exec, respec‐
227 tively (or, if the error occurs after the calling process successfully
228 returns, the child process shall exit with exit status 127).
229 If POSIX_SPAWN_SETPGROUP is set in the spawn-flags attribute of the
231 object referenced by attrp, and posix_spawn() or posix_spawnp() fails
232 while changing the child's process group, an error value shall be
233 returned as described by setpgid() (or, if the error occurs after the
234 calling process successfully returns, the child process shall exit with
235 exit status 127).
236 If POSIX_SPAWN_SETSCHEDPARAM is set and POSIX_SPAWN_SETSCHEDULER is not
238 set in the spawn-flags attribute of the object referenced by attrp,
239 then if posix_spawn() or posix_spawnp() fails for any of the reasons
240 that would cause sched_setparam() to fail, an error value shall be
241 returned as described by sched_setparam() (or, if the error occurs
242 after the calling process successfully returns, the child process shall
243 exit with exit status 127).
244 If POSIX_SPAWN_SETSCHEDULER is set in the spawn-flags attribute of the
246 object referenced by attrp, and if posix_spawn() or posix_spawnp()
247 fails for any of the reasons that would cause sched_setscheduler() to
248 fail, an error value shall be returned as described by sched_setsched‐
249 uler() (or, if the error occurs after the calling process successfully
250 returns, the child process shall exit with exit status 127).
251 If the file_actions argument is not NULL, and specifies any close,
253 dup2, or open actions to be performed, and if posix_spawn() or
254 posix_spawnp() fails for any of the reasons that would cause close(),
255 dup2(), or open() to fail, an error value shall be returned as
256 described by close(), dup2(), and open(), respectively (or, if the
257 error occurs after the calling process successfully returns, the child
258 process shall exit with exit status 127). An open file action may, by
259 itself, result in any of the errors described by close() or dup2(), in
260 addition to those described by open().
261 The following sections are informative.
263
265 None.
266
268 These functions are part of the Spawn option and need not be provided
269 on all implementations.
270
272 The posix_spawn() function and its close relation posix_spawnp() have
273 been introduced to overcome the following perceived difficulties with
274 fork(): the fork() function is difficult or impossible to implement
275 without swapping or dynamic address translation.
276 * Swapping is generally too slow for a realtime environment.
278 * Dynamic address translation is not available everywhere that POSIX
280 might be useful.
281 * Processes are too useful to simply option out of POSIX whenever it
283 must run without address translation or other MMU services.
284 Thus, POSIX needs process creation and file execution primitives that
286 can be efficiently implemented without address translation or other MMU
287 services.
288 The posix_spawn() function is implementable as a library routine, but
290 both posix_spawn() and posix_spawnp() are designed as kernel opera‐
291 tions. Also, although they may be an efficient replacement for many
292 fork()/ exec pairs, their goal is to provide useful process creation
293 primitives for systems that have difficulty with fork(), not to provide
294 drop-in replacements for fork()/ exec.
295 This view of the role of posix_spawn() and posix_spawnp() influenced
297 the design of their API. It does not attempt to provide the full func‐
298 tionality of fork()/ exec in which arbitrary user-specified operations
299 of any sort are permitted between the creation of the child process and
300 the execution of the new process image; any attempt to reach that level
301 would need to provide a programming language as parameters. Instead,
302 posix_spawn() and posix_spawnp() are process creation primitives like
303 the Start_Process and Start_Process_Search Ada language bindings pack‐
304 age POSIX_Process_Primitives and also like those in many operating sys‐
305 tems that are not UNIX systems, but with some POSIX-specific additions.
306 To achieve its coverage goals, posix_spawn() and posix_spawnp() have
308 control of six types of inheritance: file descriptors, process group
309 ID, user and group ID, signal mask, scheduling, and whether each signal
310 ignored in the parent will remain ignored in the child, or be reset to
311 its default action in the child.
312 Control of file descriptors is required to allow an independently writ‐
314 ten child process image to access data streams opened by and even gen‐
315 erated or read by the parent process without being specifically coded
316 to know which parent files and file descriptors are to be used. Control
317 of the process group ID is required to control how the child process'
318 job control relates to that of the parent.
319 Control of the signal mask and signal defaulting is sufficient to sup‐
321 port the implementation of system(). Although support for system() is
322 not explicitly one of the goals for posix_spawn() and posix_spawnp(),
323 it is covered under the "at least 50%" coverage goal.
324 The intention is that the normal file descriptor inheritance across
326 fork(), the subsequent effect of the specified spawn file actions, and
327 the normal file descriptor inheritance across one of the exec family of
328 functions should fully specify open file inheritance. The implementa‐
329 tion need make no decisions regarding the set of open file descriptors
330 when the child process image begins execution, those decisions having
331 already been made by the caller and expressed as the set of open file
332 descriptors and their FD_CLOEXEC flags at the time of the call and the
333 spawn file actions object specified in the call. We have been assured
334 that in cases where the POSIX Start_Process Ada primitives have been
335 implemented in a library, this method of controlling file descriptor
336 inheritance may be implemented very easily.
337 We can identify several problems with posix_spawn() and posix_spawnp(),
339 but there does not appear to be a solution that introduces fewer prob‐
340 lems. Environment modification for child process attributes not speci‐
341 fiable via the attrp or file_actions arguments must be done in the par‐
342 ent process, and since the parent generally wants to save its context,
343 it is more costly than similar functionality with fork()/ exec. It is
344 also complicated to modify the environment of a multi-threaded process
345 temporarily, since all threads must agree when it is safe for the envi‐
346 ronment to be changed. However, this cost is only borne by those invo‐
347 cations of posix_spawn() and posix_spawnp() that use the additional
348 functionality. Since extensive modifications are not the usual case,
349 and are particularly unlikely in time-critical code, keeping much of
350 the environment control out of posix_spawn() and posix_spawnp() is
351 appropriate design.
352 The posix_spawn() and posix_spawnp() functions do not have all the
354 power of fork()/ exec. This is to be expected. The fork() function is
355 a wonderfully powerful operation. We do not expect to duplicate its
356 functionality in a simple, fast function with no special hardware
357 requirements. It is worth noting that posix_spawn() and posix_spawnp()
358 are very similar to the process creation operations on many operating
359 systems that are not UNIX systems.
360 Requirements
362 The requirements for posix_spawn() and posix_spawnp() are:
363 * They must be implementable without an MMU or unusual hardware.
365 * They must be compatible with existing POSIX standards.
367 Additional goals are:
369 * They should be efficiently implementable.
371 * They should be able to replace at least 50% of typical executions of
373 fork().
374 * A system with posix_spawn() and posix_spawnp() and without fork()
376 should be useful, at least for realtime applications.
377 * A system with fork() and the exec family should be able to implement
379 posix_spawn() and posix_spawnp() as library routines.
380 Two-Syntax
382 POSIX exec has several calling sequences with approximately the same
383 functionality. These appear to be required for compatibility with
384 existing practice. Since the existing practice for the posix_spawn*()
385 functions is otherwise substantially unlike POSIX, we feel that sim‐
386 plicity outweighs compatibility. There are, therefore, only two names
387 for the posix_spawn*() functions.
388 The parameter list does not differ between posix_spawn() and
390 posix_spawnp(); posix_spawnp() interprets the second parameter more
391 elaborately than posix_spawn().
392 Compatibility with POSIX.5 (Ada)
394 The Start_Process and Start_Process_Search procedures from the
395 POSIX_Process_Primitives package from the Ada language binding to
396 POSIX.1 encapsulate fork() and exec functionality in a manner similar
397 to that of posix_spawn() and posix_spawnp(). Originally, in keeping
398 with our simplicity goal, the standard developers had limited the capa‐
399 bilities of posix_spawn() and posix_spawnp() to a subset of the capa‐
400 bilities of Start_Process and Start_Process_Search; certain non-default
401 capabilities were not supported. However, based on suggestions by the
402 ballot group to improve file descriptor mapping or drop it, and on the
403 advice of an Ada Language Bindings working group member, the standard
404 developers decided that posix_spawn() and posix_spawnp() should be suf‐
405 ficiently powerful to implement Start_Process and Start_Process_Search.
406 The rationale is that if the Ada language binding to such a primitive
407 had already been approved as an IEEE standard, there can be little jus‐
408 tification for not approving the functionally-equivalent parts of a C
409 binding. The only three capabilities provided by posix_spawn() and
410 posix_spawnp() that are not provided by Start_Process and
411 Start_Process_Search are optionally specifying the child's process
412 group ID, the set of signals to be reset to default signal handling in
413 the child process, and the child's scheduling policy and parameters.
414 For the Ada language binding for Start_Process to be implemented with
416 posix_spawn(), that binding would need to explicitly pass an empty sig‐
417 nal mask and the parent's environment to posix_spawn() whenever the
418 caller of Start_Process allowed these arguments to default, since
419 posix_spawn() does not provide such defaults. The ability of
420 Start_Process to mask user-specified signals during its execution is
421 functionally unique to the Ada language binding and must be dealt with
422 in the binding separately from the call to posix_spawn().
423 Process Group
425 The process group inheritance field can be used to join the child
426 process with an existing process group. By assigning a value of zero to
427 the spawn-pgroup attribute of the object referenced by attrp, the
428 setpgid() mechanism will place the child process in a new process
429 group.
430 Threads
432 Without the posix_spawn() and posix_spawnp() functions, systems without
433 address translation can still use threads to give an abstraction of
434 concurrency. In many cases, thread creation suffices, but it is not
435 always a good substitute. The posix_spawn() and posix_spawnp() func‐
436 tions are considerably "heavier" than thread creation. Processes have
437 several important attributes that threads do not. Even without address
438 translation, a process may have base-and-bound memory protection. Each
439 process has a process environment including security attributes and
440 file capabilities, and powerful scheduling attributes. Processes
441 abstract the behavior of non-uniform-memory-architecture multi-proces‐
442 sors better than threads, and they are more convenient to use for
443 activities that are not closely linked.
444 The posix_spawn() and posix_spawnp() functions may not bring support
446 for multiple processes to every configuration. Process creation is not
447 the only piece of operating system support required to support multiple
448 processes. The total cost of support for multiple processes may be
449 quite high in some circumstances. Existing practice shows that support
450 for multiple processes is uncommon and threads are common among "tiny
451 kernels". There should, therefore, probably continue to be AEPs for
452 operating systems with only one process.
453 Asynchronous Error Notification
455 A library implementation of posix_spawn() or posix_spawnp() may not be
456 able to detect all possible errors before it forks the child process.
457 IEEE Std 1003.1-2001 provides for an error indication returned from a
458 child process which could not successfully complete the spawn operation
459 via a special exit status which may be detected using the status value
460 returned by wait() and waitpid().
461 The stat_val interface and the macros used to interpret it are not well
463 suited to the purpose of returning API errors, but they are the only
464 path available to a library implementation. Thus, an implementation
465 may cause the child process to exit with exit status 127 for any error
466 detected during the spawn process after the posix_spawn() or
467 posix_spawnp() function has successfully returned.
468 The standard developers had proposed using two additional macros to
470 interpret stat_val. The first, WIFSPAWNFAIL, would have detected a sta‐
471 tus that indicated that the child exited because of an error detected
472 during the posix_spawn() or posix_spawnp() operations rather than dur‐
473 ing actual execution of the child process image; the second, WSPAWN‐
474 ERRNO, would have extracted the error value if WIFSPAWNFAIL indicated a
475 failure. Unfortunately, the ballot group strongly opposed this because
476 it would make a library implementation of posix_spawn() or
477 posix_spawnp() dependent on kernel modifications to waitpid() to be
478 able to embed special information in stat_val to indicate a spawn fail‐
479 ure.
480 The 8 bits of child process exit status that are guaranteed by
482 IEEE Std 1003.1-2001 to be accessible to the waiting parent process are
483 insufficient to disambiguate a spawn error from any other kind of error
484 that may be returned by an arbitrary process image. No other bits of
485 the exit status are required to be visible in stat_val, so these macros
486 could not be strictly implemented at the library level. Reserving an
487 exit status of 127 for such spawn errors is consistent with the use of
488 this value by system() and popen() to signal failures in these opera‐
489 tions that occur after the function has returned but before a shell is
490 able to execute. The exit status of 127 does not uniquely identify this
491 class of error, nor does it provide any detailed information on the
492 nature of the failure. Note that a kernel implementation of
493 posix_spawn() or posix_spawnp() is permitted (and encouraged) to return
494 any possible error as the function value, thus providing more detailed
495 failure information to the parent process.
496 Thus, no special macros are available to isolate asynchronous
498 posix_spawn() or posix_spawnp() errors. Instead, errors detected by the
499 posix_spawn() or posix_spawnp() operations in the context of the child
500 process before the new process image executes are reported by setting
501 the child's exit status to 127. The calling process may use the WIFEX‐
502 ITED and WEXITSTATUS macros on the stat_val stored by the wait() or
503 waitpid() functions to detect spawn failures to the extent that other
504 status values with which the child process image may exit (before the
505 parent can conclusively determine that the child process image has
506 begun execution) are distinct from exit status 127.
507
509 None.
510
512 alarm(), chmod(), close(), dup(), exec(), exit(), fcntl(), fork(),
513 kill(), open(), posix_spawn_file_actions_addclose(),
514 posix_spawn_file_actions_adddup2(), posix_spawn_file_actions_addopen(),
515 posix_spawn_file_actions_destroy(), posix_spawnattr_destroy(),
516 posix_spawnattr_init(), posix_spawnattr_getsigdefault(), posix_spaw‐
517 nattr_getflags(), posix_spawnattr_getpgroup(), posix_spaw‐
518 nattr_getschedparam(), posix_spawnattr_getschedpolicy(), posix_spaw‐
519 nattr_getsigmask(), posix_spawnattr_setsigdefault(), posix_spaw‐
520 nattr_setflags(), posix_spawnattr_setpgroup(), posix_spaw‐
521 nattr_setschedparam(), posix_spawnattr_setschedpolicy(), posix_spaw‐
522 nattr_setsigmask(), sched_setparam(), sched_setscheduler(), setpgid(),
523 setuid(), stat(), times(), wait(), the Base Definitions volume of
524 IEEE Std 1003.1-2001, <spawn.h>
525
527 Portions of this text are reprinted and reproduced in electronic form
528 from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
529 -- Portable Operating System Interface (POSIX), The Open Group Base
530 Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
531 Electrical and Electronics Engineers, Inc and The Open Group. In the
532 event of any discrepancy between this version and the original IEEE and
533 The Open Group Standard, the original IEEE and The Open Group Standard
534 is the referee document. The original Standard can be obtained online
535 at http://www.opengroup.org/unix/online.html .
536IEEE/The Open Group 2003 POSIX_SPAWN(3P)