svcadm(1M)을 검색하려면 섹션에서 1M 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
forkall(2)
fork(2) System Calls fork(2)
NAME
fork, fork1, forkall, forkx, forkallx - create a new process
SYNOPSIS
#include <sys/types.h>
#include <unistd.h>
pid_t fork(void);
pid_t fork1(void);
pid_t forkall(void);
#include <sys/fork.h>
pid_t forkx(int flags);
pid_t forkallx(int flags);
DESCRIPTION
The fork(), fork1(), forkall(), forkx(), and forkallx() functions cre‐
ate a new process. The address space of the new process (child process)
is an exact copy of the address space of the calling process (parent
process). The child process inherits the following attributes from the
parent process:
o real user ID, real group ID, effective user ID, effective
group ID
o environment
o open file descriptors
o close-on-exec flags (see exec(2))
o signal handling settings (that is, SIG_DFL, SIG_IGN,
SIG_HOLD, function address)
o supplementary group IDs
o set-user-ID mode bit
o set-group-ID mode bit
o profiling on/off status
o nice value (see nice(2))
o scheduler class (see priocntl(2))
o all attached shared memory segments (see shmop(2))
o process group ID -- memory mappings (see mmap(2))
o session ID (see exit(2))
o current working directory
o extended policy and related flags (see privileges(7) and
setpflags(2))
o root directory
o file mode creation mask (see umask(2))
o resource limits (see getrlimit(2))
o controlling terminal
o saved user ID and group ID
o task ID and project ID
o processor bindings (see processor_bind(2))
o processor set bindings (see pset_bind(2))
o process privilege sets and the extended policy (see getp‐
priv(2) and privileges(7))
o process flags (see getpflags(2))
o active contract templates (see contract(5))
o security extension configuration (see sxadm(8))
Scheduling priority and any per-process scheduling parameters that are
specific to a given scheduling class might or might not be inherited
according to the policy of that particular class (see priocntl(2)). The
child process might or might not be in the same process contract as the
parent (see process(5)). The child process differs from the parent
process in the following ways:
o The child process has a unique process ID which does not
match any active process group ID.
o The child process has a different parent process ID (that
is, the process ID of the parent process).
o The child process has its own copy of the parent's file
descriptors and directory streams except as described below.
Each of the child's file descriptors shares a common file
pointer with the corresponding file descriptor of the par‐
ent.
o Each shared memory segment remains attached and the value of
shm_nattach is incremented by 1.
o All semadj values are cleared (see semop(2)).
o Process locks, text locks, data locks, and other memory
locks are not inherited by the child (see plock(3C) and mem‐
cntl(2)).
o The child process's tms structure is cleared: tms_utime,
stime, cutime, and cstime are set to 0 (see times(2)).
o The child processes resource utilizations are set to 0; see
getrlimit(2). The it_value and it_interval values for the
ITIMER_REAL timer are reset to 0; see getitimer(2).
o The set of signals pending for the child process is initial‐
ized to the empty set.
o Timers created by timer_create(3C) are not inherited by the
child process.
o No asynchronous input or asynchronous output operations are
inherited by the child.
o Any preferred hardware address translation sizes (see memc‐
ntl(2)) are inherited by the child.
o The child process holds no contracts (see contract(5)).
Record locks set by the parent process are not inherited by the child
process (see fcntl(2)).
File descriptors remain open in the child process, except for those
whose close-on-fork flag FD_CLOFORK is set; see fcntl(2). Note that
FD_CLOFORK does not duplicate then close a file descriptor across a
fork() function: instead, the descriptor is not made available to the
child process.
Although any open door descriptors in the parent are shared by the
child, only the parent will receive a door invocation from clients even
if the door descriptor is open in the child. If a descriptor is closed
in the parent, attempts to operate on the door descriptor will fail
even if it is still open in the child.
Fork Extensions
The forkx() and forkallx() functions accept a flags argument consisting
of a bitwise inclusive-OR of zero or more of the following flags, which
are defined in the header <sys/fork.h>:
FORK_NOSIGCHLD
Do not post a SIGCHLD signal to the parent process when the child
process terminates, regardless of the disposition of the SIGCHLD
signal in the parent. SIGCHLD signals are still possible for job
control stop and continue actions if the parent has requested them.
FORK_WAITPID
Do not allow wait-for-multiple-pids by the parent, as in wait(),
waitid(P_ALL), or waitid(P_PGID), to reap the child and do not
allow the child to be reaped automatically due to the disposition
of the SIGCHLD signal being set to be ignored in the parent. Only a
specific wait for the child, as in waitid(P_PID, pid), is allowed
and it is required, else when the child exits it will remain a zom‐
bie until the parent exits.
If the flags argument is 0, forkx() is identical to fork() and
forkallx() is identical to forkall().
Threads
A call to forkall() or forkallx() replicates in the child process all
of the threads (see thr_create(3C) and pthread_create(3C)) in the par‐
ent process. A call to fork1() or forkx() replicates only the calling
thread in the child process.
A call to fork() is identical to a call to fork1(); only the calling
thread is replicated in the child process. This is the POSIX-specified
behavior for fork().
In releases of Solaris prior to Solaris 10, the behavior of fork()
depended on whether or not the application was linked with the POSIX
threads library. When linked with -lthread (Solaris Threads) but not
linked with -lpthread (POSIX Threads), fork() was the same as
forkall(). When linked with -lpthread, whether or not also linked with
-lthread, fork() was the same as fork1().
Prior to Solaris 10, either -lthread or -lpthread was required for mul‐
tithreaded applications. This is no longer the case. The standard C
library provides all threading support for both sets of application
programming interfaces. Applications that require replicate-all fork
semantics must call forkall() or forkallx().
fork() Safety
If a multithreaded application calls fork(), fork1(), or forkx(), and
the child does more than simply call one of the exec(2) functions,
there is a possibility of deadlock occurring in the child. The applica‐
tion should use pthread_atfork(3C) to ensure safety with respect to
this deadlock. Should there be any outstanding mutexes throughout the
process, the application should call pthread_atfork() to wait for and
acquire those mutexes prior to calling fork(), fork1(), or forkx(). See
"MT-Level" in attributes(7).
The pthread_atfork() mechanism is used to protect the locks that
libc(3LIB) uses to implement interfaces such as malloc(3C). All inter‐
faces provided by libc are safe to use in a child process following a
fork(), except when fork() is executed within a signal handler.
The POSIX standard (see standards(7)) requires fork to be Async-Signal-
Safe (see attributes(7)). This cannot be made to happen with fork han‐
dlers in place, because they acquire locks. To be in nominal compli‐
ance, no fork handlers are called when fork() is executed within a sig‐
nal context. This leaves the child process in a questionable state with
respect to its locks, but at least the calling thread will not deadlock
itself attempting to acquire a lock that it already owns. In this situ‐
ation, the application should strictly adhere to the advice given in
the POSIX specification: "To avoid errors, the child process may only
execute Async-Signal-Safe operations until such time as one of the
exec(2) functions is called."
RETURN VALUES
Upon successful completion, fork(), fork1(), forkall(), forkx(), and
forkallx() return 0 to the child process and return the process ID of
the child process to the parent process. Otherwise, (pid_t)−1 is
returned to the parent process, no child process is created, and errno
is set to indicate the error.
ERRORS
The fork(), fork1(), forkall(), forkx(), and forkallx() functions will
fail if:
EAGAIN A resource control or limit on the total number of processes,
tasks or LWPs under execution by a single user, task,
project, or zone has been exceeded, or the total amount of
system memory available is temporarily insufficient to dupli‐
cate this process.
An operation would exceed a limit or resource control on ADI
memory.
ENOMEM There is not enough swap space.
EPERM The {PRIV_PROC_FORK} privilege is not asserted in the effec‐
tive set of the calling process.
The forkx() and forkallx() functions will fail if:
EINVAL The flags argument is invalid.
ATTRIBUTES
See attributes(7) for descriptions of the following attributes:
tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRIBUTE TYPEAT‐
TRIBUTE VALUE _ Interface StabilityCommitted _ MT-LevelAsync-Signal-
Safe. _ StandardSee below.
For fork(), see standards(7).
SEE ALSO
memcntl(2), alarm(2), exec(2), exit(2), fcntl(2), getitimer(2), getr‐
limit(2), mmap(2), nice(2), priocntl(2), semop(2), shmop(2), spawn(2),
times(2), umask(2), waitid(2), door_create(3C), exit(3C), plock(3C),
posix_spawn(3C), pthread_atfork(3C), pthread_create(3C), signal(3C),
system(3C), thr_create(3C), timer_create(3C), wait(3C), contract(5),
process(5), attributes(7), privileges(7), standards(7)
NOTES
An application should call _exit() rather than exit(3C) if it cannot
execve(), since exit() will flush and close standard I/O channels and
thereby corrupt the parent process's standard I/O data structures.
Using exit(3C) will flush buffered data twice. See exit(2).
The thread in the child that calls fork(), fork1(), or forkx() must not
depend on any resources held by threads that no longer exist in the
child. In particular, locks held by these threads will not be released.
In a multithreaded process, forkall() in one thread can cause blocking
system calls to be interrupted and return with an EINTR error.
The design of posix_spawn(3C) avoids many of the issues that can occur
during the window between fork and exec system calls. When possible,
the use of posix_spawn(3C) is recommended, in preference to the fork
functions documented here.
Oracle Solaris 11.4 27 Mar 2020 fork(2)