posix_spawnp man page on CentOS

Man page or keyword search:  
man Server   8420 pages
apropos Keyword Search (all sections)
Output format
CentOS logo
[printable version]

POSIX_SPAWN(P)		   POSIX Programmer's Manual		POSIX_SPAWN(P)

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

NAME
       posix_spawn, posix_spawnp - spawn a process (ADVANCED REALTIME)

SYNOPSIS
       #include <spawn.h>

       int posix_spawn(pid_t *restrict pid, const char *restrict path,
	      const posix_spawn_file_actions_t *file_actions,
	      const posix_spawnattr_t *restrict attrp,
	      char *const argv[restrict], char *const envp[restrict]);
       int posix_spawnp(pid_t *restrict pid, const char *restrict file,
	      const posix_spawn_file_actions_t *file_actions,
	      const posix_spawnattr_t *restrict attrp,
	      char *const argv[restrict], char * const envp[restrict]);

DESCRIPTION
       The posix_spawn() and  posix_spawnp()  functions	 shall	create	a  new
       process	(child	process)  from	the  specified	process image. The new
       process image shall be  constructed  from  a  regular  executable  file
       called the new process image file.

       When  a	C  program is executed as the result of this call, it shall be
       entered as a C-language function call as follows:

	      int main(int argc, char *argv[]);

       where argc is the argument count and argv  is  an  array	 of  character
       pointers	 to the arguments themselves. In addition, the following vari‐
       able:

	      extern char **environ;

       shall be initialized as a pointer to an array of character pointers  to
       the environment strings.

       The  argument argv is an array of character pointers to null-terminated
       strings. The last member of this array shall be a null pointer  and  is
       not  counted in argc. These strings constitute the argument list avail‐
       able to the new process image. The value in argv[0] should point	 to  a
       filename that is associated with the process image being started by the
       posix_spawn() or posix_spawnp() function.

       The argument envp is an array of character pointers to  null-terminated
       strings.	 These	strings constitute the environment for the new process
       image. The environment array is terminated by a null pointer.

       The number of bytes available for the child process' combined  argument
       and environment lists is {ARG_MAX}. The implementation shall specify in
       the  system  documentation  (see	 the  Base   Definitions   volume   of
       IEEE Std 1003.1-2001,  Chapter  2,  Conformance) whether any list over‐
       head, such as length words, null terminators,  pointers,	 or  alignment
       bytes, is included in this total.

       The  path  argument  to posix_spawn() is a pathname that identifies the
       new process image file to execute.

       The file parameter to posix_spawnp() shall be used to construct a path‐
       name  that identifies the new process image file. If the file parameter
       contains a slash character, the file parameter shall  be	 used  as  the
       pathname for the new process image file. Otherwise, the path prefix for
       this file shall be obtained by a search of the  directories  passed  as
       the  environment	 variable  PATH	 (see  the  Base Definitions volume of
       IEEE Std 1003.1-2001, Chapter 8, Environment Variables). If this	 envi‐
       ronment	variable  is not defined, the results of the search are imple‐
       mentation-defined.

       If file_actions is a null pointer, then file descriptors	 open  in  the
       calling	process	 shall	remain	open  in the child process, except for
       those whose close-on- exec flag FD_CLOEXEC is set (see fcntl()  ).  For
       those  file  descriptors that remain open, all attributes of the corre‐
       sponding open file descriptions, including file locks (see  fcntl()  ),
       shall remain unchanged.

       If  file_actions	 is  not  NULL,	 then the file descriptors open in the
       child process shall be those open in the calling process as modified by
       the  spawn  file	 actions  object  pointed  to  by file_actions and the
       FD_CLOEXEC flag of each remaining open file descriptor after the	 spawn
       file  actions  have  been processed.  The effective order of processing
       the spawn file actions shall be:

	1. The set of open file descriptors for the child process  shall  ini‐
	   tially  be  the  same  set  as is open for the calling process. All
	   attributes of the corresponding open file  descriptions,  including
	   file locks (see fcntl() ), shall remain unchanged.

	2. The signal mask, signal default actions, and the effective user and
	   group IDs for the child process shall be changed  as	 specified  in
	   the attributes object referenced by attrp.

	3. The	file  actions specified by the spawn file actions object shall
	   be performed in the order in which they were	 added	to  the	 spawn
	   file actions object.

	4. Any file descriptor that has its FD_CLOEXEC flag set (see fcntl() )
	   shall be closed.

       The posix_spawnattr_t  spawn  attributes	 object	 type  is  defined  in
       <spawn.h>. It shall contain at least the attributes defined below.

       If  the	POSIX_SPAWN_SETPGROUP flag is set in the spawn-flags attribute
       of the object referenced by attrp, and the  spawn-pgroup	 attribute  of
       the same object is non-zero, then the child's process group shall be as
       specified in the spawn-pgroup attribute of  the	object	referenced  by
       attrp.

       As  a  special  case,  if  the POSIX_SPAWN_SETPGROUP flag is set in the
       spawn-flags attribute of the object referenced by attrp, and the spawn-
       pgroup  attribute  of  the  same	 object is set to zero, then the child
       shall be in a new process group with a process group ID	equal  to  its
       process ID.

       If  the	POSIX_SPAWN_SETPGROUP  flag  is	 not  set  in  the spawn-flags
       attribute of the object referenced by  attrp,  the  new	child  process
       shall inherit the parent's process group.

       If  the	POSIX_SPAWN_SETSCHEDPARAM  flag	 is  set  in  the  spawn-flags
       attribute of the object referenced by attrp, but	 POSIX_SPAWN_SETSCHED‐
       ULER  is not set, the new process image shall initially have the sched‐
       uling policy of the calling  process  with  the	scheduling  parameters
       specified in the spawn-schedparam attribute of the object referenced by
       attrp.

       If  the	POSIX_SPAWN_SETSCHEDULER  flag	is  set	 in  the   spawn-flags
       attribute  of the object referenced by attrp (regardless of the setting
       of the POSIX_SPAWN_SETSCHEDPARAM flag), the  new	 process  image	 shall
       initially have the scheduling policy specified in the spawn-schedpolicy
       attribute of the object referenced by attrp and the scheduling  parame‐
       ters specified in the spawn-schedparam attribute of the same object.

       The  POSIX_SPAWN_RESETIDS  flag	in  the	 spawn-flags  attribute of the
       object referenced by attrp governs the effective user ID of  the	 child
       process.	 If  this flag is not set, the child process shall inherit the
       parent process' effective user ID. If  this  flag  is  set,  the	 child
       process' effective user ID shall be reset to the parent's real user ID.
       In either case, if the set-user-ID mode bit of the  new	process	 image
       file  is	 set,  the effective user ID of the child process shall become
       that file's owner ID before the new process image begins execution.

       The POSIX_SPAWN_RESETIDS flag  in  the  spawn-flags  attribute  of  the
       object  referenced  by attrp also governs the effective group ID of the
       child process. If this flag is not set, the child process shall inherit
       the  parent process' effective group ID. If this flag is set, the child
       process' effective group ID shall be reset to the parent's  real	 group
       ID.  In	either	case,  if the set-group-ID mode bit of the new process
       image file is set, the effective group ID of the	 child	process	 shall
       become  that file's group ID before the new process image begins execu‐
       tion.

       If the POSIX_SPAWN_SETSIGMASK flag is set in the spawn-flags  attribute
       of  the	object	referenced by attrp, the child process shall initially
       have the signal mask specified in the spawn-sigmask  attribute  of  the
       object referenced by attrp.

       If  the	POSIX_SPAWN_SETSIGDEF flag is set in the spawn-flags attribute
       of the object referenced by attrp, the signals specified in the	spawn-
       sigdefault  attribute  of the same object shall be set to their default
       actions in the child process. Signals set to the default action in  the
       parent process shall be set to the default action in the child process.

       Signals	set  to	 be  caught by the calling process shall be set to the
       default action in the child process.

       Except for SIGCHLD, signals set to be ignored by	 the  calling  process
       image shall be set to be ignored by the child process, unless otherwise
       specified by the POSIX_SPAWN_SETSIGDEF flag being  set  in  the	spawn-
       flags attribute of the object referenced by attrp and the signals being
       indicated in the spawn-sigdefault attribute of the object referenced by
       attrp.

       If  the	SIGCHLD signal is set to be ignored by the calling process, it
       is unspecified whether the SIGCHLD signal is set to be  ignored	or  to
       the  default action in the child process, unless otherwise specified by
       the POSIX_SPAWN_SETSIGDEF flag being set in the	spawn_flags  attribute
       of  the	object	referenced by attrp and the SIGCHLD signal being indi‐
       cated in the spawn_sigdefault attribute of  the	object	referenced  by
       attrp.

       If  the value of the attrp pointer is NULL, then the default values are
       used.

       All process attributes, other than those influenced by  the  attributes
       set in the object referenced by attrp as specified above or by the file
       descriptor manipulations specified in file_actions, shall appear in the
       new  process  image  as though fork() had been called to create a child
       process and then a member of the exec  family  of  functions  had  been
       called by the child process to execute the new process image.

       It  is  implementation-defined  whether	the fork handlers are run when
       posix_spawn() or posix_spawnp() is called.

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

ERRORS
       The posix_spawn() and posix_spawnp() functions may fail if:

       EINVAL The value specified by file_actions or attrp is invalid.

       If  this	 error	occurs	after the calling process successfully returns
       from the posix_spawn() or posix_spawnp() function,  the	child  process
       may exit with exit status 127.

       If  posix_spawn()  or  posix_spawnp()  fail for any of the reasons that
       would cause fork() or one of the exec family of functions to  fail,  an
       error  value shall be returned as described by fork() and exec, respec‐
       tively (or, if the error occurs after the calling process  successfully
       returns, the child process shall exit with exit status 127).

       If  POSIX_SPAWN_SETPGROUP  is  set  in the spawn-flags attribute of the
       object referenced by attrp, and posix_spawn() or	 posix_spawnp()	 fails
       while  changing	the  child's  process  group,  an error value shall be
       returned as described by setpgid() (or, if the error occurs  after  the
       calling process successfully returns, the child process shall exit with
       exit status 127).

       If POSIX_SPAWN_SETSCHEDPARAM is set and POSIX_SPAWN_SETSCHEDULER is not
       set  in	the  spawn-flags  attribute of the object referenced by attrp,
       then if posix_spawn() or posix_spawnp() fails for any  of  the  reasons
       that  would  cause  sched_setparam()  to	 fail, an error value shall be
       returned as described by sched_setparam()  (or,	if  the	 error	occurs
       after the calling process successfully returns, the child process shall
       exit with exit status 127).

       If POSIX_SPAWN_SETSCHEDULER is set in the spawn-flags attribute of  the
       object  referenced  by  attrp,  and  if posix_spawn() or posix_spawnp()
       fails for any of the reasons that would cause  sched_setscheduler()  to
       fail,  an error value shall be returned as described by sched_setsched‐
       uler() (or, if the error occurs after the calling process  successfully
       returns, the child process shall exit with exit status 127).

       If  the	file_actions  argument	is  not NULL, and specifies any close,
       dup2, or	 open  actions	to  be	performed,  and	 if  posix_spawn()  or
       posix_spawnp()  fails  for any of the reasons that would cause close(),
       dup2(), or open()  to  fail,  an	 error	value  shall  be  returned  as
       described  by  close(),	dup2(),	 and  open(), respectively (or, if the
       error occurs after the calling process successfully returns, the	 child
       process	shall  exit with exit status 127). An open file action may, by
       itself, result in any of the errors described by close() or dup2(),  in
       addition to those described by open().

       The following sections are informative.

EXAMPLES
       None.

APPLICATION USAGE
       These  functions	 are part of the Spawn option and need not be provided
       on all implementations.

RATIONALE
       The posix_spawn() function and its close relation  posix_spawnp()  have
       been  introduced	 to overcome the following perceived difficulties with
       fork(): the fork() function is difficult	 or  impossible	 to  implement
       without swapping or dynamic address translation.

	* Swapping is generally too slow for a realtime environment.

	* Dynamic  address  translation is not available everywhere that POSIX
	  might be useful.

	* Processes are too useful to simply option out of POSIX  whenever  it
	  must run without address translation or other MMU services.

       Thus,  POSIX  needs process creation and file execution primitives that
       can be efficiently implemented without address translation or other MMU
       services.

       The  posix_spawn()  function is implementable as a library routine, but
       both posix_spawn() and posix_spawnp() are  designed  as	kernel	opera‐
       tions.  Also,  although	they  may be an efficient replacement for many
       fork()/ exec pairs, their goal is to provide  useful  process  creation
       primitives for systems that have difficulty with fork(), not to provide
       drop-in replacements for fork()/ exec.

       This view of the role of posix_spawn()  and  posix_spawnp()  influenced
       the  design of their API. It does not attempt to provide the full func‐
       tionality of fork()/ exec in which arbitrary user-specified  operations
       of any sort are permitted between the creation of the child process and
       the execution of the new process image; any attempt to reach that level
       would  need  to	provide a programming language as parameters. Instead,
       posix_spawn() and posix_spawnp() are process creation  primitives  like
       the  Start_Process and Start_Process_Search Ada language bindings pack‐
       age POSIX_Process_Primitives and also like those in many operating sys‐
       tems that are not UNIX systems, but with some POSIX-specific additions.

       To  achieve  its	 coverage goals, posix_spawn() and posix_spawnp() have
       control of six types of inheritance: file  descriptors,	process	 group
       ID, user and group ID, signal mask, scheduling, and whether each signal
       ignored in the parent will remain ignored in the child, or be reset  to
       its default action in the child.

       Control of file descriptors is required to allow an independently writ‐
       ten child process image to access data streams opened by and even  gen‐
       erated  or  read by the parent process without being specifically coded
       to know which parent files and file descriptors are to be used. Control
       of  the	process group ID is required to control how the child process'
       job control relates to that of the parent.

       Control of the signal mask and signal defaulting is sufficient to  sup‐
       port  the  implementation of system(). Although support for system() is
       not explicitly one of the goals for posix_spawn()  and  posix_spawnp(),
       it is covered under the "at least 50%" coverage goal.

       The  intention  is  that	 the normal file descriptor inheritance across
       fork(), the subsequent effect of the specified spawn file actions,  and
       the normal file descriptor inheritance across one of the exec family of
       functions should fully specify open file inheritance.  The  implementa‐
       tion  need make no decisions regarding the set of open file descriptors
       when the child process image begins execution, those  decisions	having
       already	been  made by the caller and expressed as the set of open file
       descriptors and their FD_CLOEXEC flags at the time of the call and  the
       spawn  file  actions object specified in the call. We have been assured
       that in cases where the POSIX Start_Process Ada	primitives  have  been
       implemented  in	a  library, this method of controlling file descriptor
       inheritance may be implemented very easily.

       We can identify several problems with posix_spawn() and posix_spawnp(),
       but  there does not appear to be a solution that introduces fewer prob‐
       lems. Environment modification for child process attributes not	speci‐
       fiable via the attrp or file_actions arguments must be done in the par‐
       ent process, and since the parent generally wants to save its  context,
       it  is more costly than similar functionality with fork()/ exec.	 It is
       also complicated to modify the environment of a multi-threaded  process
       temporarily, since all threads must agree when it is safe for the envi‐
       ronment to be changed. However, this cost is only borne by those	 invo‐
       cations	of  posix_spawn()  and	posix_spawnp() that use the additional
       functionality. Since extensive modifications are not  the  usual	 case,
       and  are	 particularly  unlikely in time-critical code, keeping much of
       the environment control out  of	posix_spawn()  and  posix_spawnp()  is
       appropriate design.

       The  posix_spawn()  and	posix_spawnp()	functions  do not have all the
       power of fork()/ exec. This is to be expected.  The fork() function  is
       a  wonderfully  powerful	 operation.  We do not expect to duplicate its
       functionality in a simple,  fast	 function  with	 no  special  hardware
       requirements.  It is worth noting that posix_spawn() and posix_spawnp()
       are very similar to the process creation operations on  many  operating
       systems that are not UNIX systems.

   Requirements
       The requirements for posix_spawn() and posix_spawnp() are:

	* They must be implementable without an MMU or unusual hardware.

	* They must be compatible with existing POSIX standards.

       Additional goals are:

	* They should be efficiently implementable.

	* They should be able to replace at least 50% of typical executions of
	  fork().

	* A system with posix_spawn() and posix_spawnp()  and  without	fork()
	  should be useful, at least for realtime applications.

	* A system with fork() and the exec family should be able to implement
	  posix_spawn() and posix_spawnp() as library routines.

   Two-Syntax
       POSIX exec has several calling sequences with  approximately  the  same
       functionality.	These  appear  to  be  required for compatibility with
       existing practice.  Since the existing practice for the	posix_spawn*()
       functions  is  otherwise	 substantially unlike POSIX, we feel that sim‐
       plicity outweighs compatibility. There are, therefore, only  two	 names
       for the posix_spawn*() functions.

       The   parameter	 list	does  not  differ  between  posix_spawn()  and
       posix_spawnp(); posix_spawnp() interprets  the  second  parameter  more
       elaborately than posix_spawn().

   Compatibility with POSIX.5 (Ada)
       The   Start_Process   and   Start_Process_Search	 procedures  from  the
       POSIX_Process_Primitives package	 from  the  Ada	 language  binding  to
       POSIX.1	encapsulate  fork() and exec functionality in a manner similar
       to that of posix_spawn() and posix_spawnp().   Originally,  in  keeping
       with our simplicity goal, the standard developers had limited the capa‐
       bilities of posix_spawn() and posix_spawnp() to a subset of  the	 capa‐
       bilities of Start_Process and Start_Process_Search; certain non-default
       capabilities were not supported. However, based on suggestions  by  the
       ballot  group to improve file descriptor mapping or drop it, and on the
       advice of an Ada Language Bindings working group member,	 the  standard
       developers decided that posix_spawn() and posix_spawnp() should be suf‐
       ficiently powerful to implement Start_Process and Start_Process_Search.
       The  rationale  is that if the Ada language binding to such a primitive
       had already been approved as an IEEE standard, there can be little jus‐
       tification  for	not approving the functionally-equivalent parts of a C
       binding. The only three	capabilities  provided	by  posix_spawn()  and
       posix_spawnp()	that   are   not   provided   by   Start_Process   and
       Start_Process_Search are	 optionally  specifying	 the  child's  process
       group  ID, the set of signals to be reset to default signal handling in
       the child process, and the child's scheduling policy and parameters.

       For the Ada language binding for Start_Process to be  implemented  with
       posix_spawn(), that binding would need to explicitly pass an empty sig‐
       nal mask and the parent's environment  to  posix_spawn()	 whenever  the
       caller  of  Start_Process  allowed  these  arguments  to default, since
       posix_spawn()  does  not	 provide  such	defaults.   The	  ability   of
       Start_Process  to  mask	user-specified signals during its execution is
       functionally unique to the Ada language binding and must be dealt  with
       in the binding separately from the call to posix_spawn().

   Process Group
       The  process  group  inheritance	 field	can  be used to join the child
       process with an existing process group. By assigning a value of zero to
       the  spawn-pgroup  attribute  of	 the  object  referenced by attrp, the
       setpgid() mechanism will place the  child  process  in  a  new  process
       group.

   Threads
       Without the posix_spawn() and posix_spawnp() functions, systems without
       address translation can still use threads to  give  an  abstraction  of
       concurrency.  In	 many  cases,  thread creation suffices, but it is not
       always a good substitute. The posix_spawn()  and	 posix_spawnp()	 func‐
       tions  are  considerably "heavier" than thread creation. Processes have
       several important attributes that threads do not. Even without  address
       translation, a process may have base-and-bound memory protection.  Each
       process has a process environment  including  security  attributes  and
       file  capabilities,  and	 powerful  scheduling  attributes.   Processes
       abstract the behavior of non-uniform-memory-architecture	 multi-proces‐
       sors  better  than  threads,  and  they	are more convenient to use for
       activities that are not closely linked.

       The posix_spawn() and posix_spawnp() functions may  not	bring  support
       for  multiple processes to every configuration. Process creation is not
       the only piece of operating system support required to support multiple
       processes.  The	total  cost  of	 support for multiple processes may be
       quite high in some circumstances.  Existing practice shows that support
       for  multiple  processes is uncommon and threads are common among "tiny
       kernels".  There should, therefore, probably continue to	 be  AEPs  for
       operating systems with only one process.

   Asynchronous Error Notification
       A  library implementation of posix_spawn() or posix_spawnp() may not be
       able to detect all possible errors before it forks the  child  process.
       IEEE Std 1003.1-2001  provides  for an error indication returned from a
       child process which could not successfully complete the spawn operation
       via  a special exit status which may be detected using the status value
       returned by wait() and waitpid().

       The stat_val interface and the macros used to interpret it are not well
       suited  to  the	purpose of returning API errors, but they are the only
       path available to a library implementation.   Thus,  an	implementation
       may  cause the child process to exit with exit status 127 for any error
       detected	 during	 the  spawn  process  after   the   posix_spawn()   or
       posix_spawnp() function has successfully returned.

       The  standard  developers  had  proposed using two additional macros to
       interpret stat_val. The first, WIFSPAWNFAIL, would have detected a sta‐
       tus  that  indicated that the child exited because of an error detected
       during the posix_spawn() or posix_spawnp() operations rather than  dur‐
       ing  actual  execution  of the child process image; the second, WSPAWN‐
       ERRNO, would have extracted the error value if WIFSPAWNFAIL indicated a
       failure.	 Unfortunately, the ballot group strongly opposed this because
       it  would  make	a   library   implementation   of   posix_spawn()   or
       posix_spawnp()  dependent  on  kernel  modifications to waitpid() to be
       able to embed special information in stat_val to indicate a spawn fail‐
       ure.

       The  8  bits  of	 child	process	 exit  status  that  are guaranteed by
       IEEE Std 1003.1-2001 to be accessible to the waiting parent process are
       insufficient to disambiguate a spawn error from any other kind of error
       that may be returned by an arbitrary process image. No  other  bits  of
       the exit status are required to be visible in stat_val, so these macros
       could not be strictly implemented at the library	 level.	 Reserving  an
       exit  status of 127 for such spawn errors is consistent with the use of
       this value by system() and popen() to signal failures in	 these	opera‐
       tions  that occur after the function has returned but before a shell is
       able to execute. The exit status of 127 does not uniquely identify this
       class  of  error,  nor  does it provide any detailed information on the
       nature  of  the	failure.  Note	that  a	  kernel   implementation   of
       posix_spawn() or posix_spawnp() is permitted (and encouraged) to return
       any possible error as the function value, thus providing more  detailed
       failure information to the parent process.

       Thus,   no   special  macros  are  available  to	 isolate  asynchronous
       posix_spawn() or posix_spawnp() errors. Instead, errors detected by the
       posix_spawn()  or posix_spawnp() operations in the context of the child
       process before the new process image executes are reported  by  setting
       the  child's exit status to 127. The calling process may use the WIFEX‐
       ITED and WEXITSTATUS macros on the stat_val stored  by  the  wait()  or
       waitpid()  functions  to detect spawn failures to the extent that other
       status values with which the child process image may exit  (before  the
       parent  can  conclusively  determine  that  the child process image has
       begun execution) are distinct from exit status 127.

FUTURE DIRECTIONS
       None.

SEE ALSO
       alarm() , chmod() , close() , dup() ,  exec()  ,	 exit()	 ,  fcntl()  ,
       fork()  ,  kill()  ,  open()  ,	posix_spawn_file_actions_addclose()  ,
       posix_spawn_file_actions_adddup2() , posix_spawn_file_actions_addopen()
       ,  posix_spawn_file_actions_destroy()  ,	 , posix_spawnattr_destroy() ,
       posix_spawnattr_init() , posix_spawnattr_getsigdefault() ,  posix_spaw‐
       nattr_getflags()	   ,	posix_spawnattr_getpgroup()    ,   posix_spaw‐
       nattr_getschedparam() , posix_spawnattr_getschedpolicy() ,  posix_spaw‐
       nattr_getsigmask()   ,  posix_spawnattr_setsigdefault()	,  posix_spaw‐
       nattr_setflags()	  ,    posix_spawnattr_setpgroup()    ,	   posix_spaw‐
       nattr_setschedparam()  , posix_spawnattr_setschedpolicy() , posix_spaw‐
       nattr_setsigmask()  ,   sched_setparam()	  ,   sched_setscheduler()   ,
       setpgid() , setuid() , stat() , times() , wait() , the Base Definitions
       volume of IEEE Std 1003.1-2001, <spawn.h>

COPYRIGHT
       Portions of this text are reprinted and reproduced in  electronic  form
       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
       -- Portable Operating System Interface (POSIX),	The  Open  Group  Base
       Specifications  Issue  6,  Copyright  (C) 2001-2003 by the Institute of
       Electrical and Electronics Engineers, Inc and The Open  Group.  In  the
       event of any discrepancy between this version and the original IEEE and
       The Open Group Standard, the original IEEE and The Open Group  Standard
       is  the	referee document. The original Standard can be obtained online
       at http://www.opengroup.org/unix/online.html .

IEEE/The Open Group		     2003			POSIX_SPAWN(P)
[top]

List of man pages available for CentOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net