3    Process Primitives

The functions described in this section perform the most primitive operating system services dealing with processes, interprocess signals, and timers.

3.1    Process Creation and Execution

3.1.1    Process Creation

3.1.1.2    Description

On the operating system, after a fork(), the new child process acquires the following process characteristics not specified by POSIX.1:

Table 3-1: Child Process Inherited Characteristics

Process Characteristics

The state of profiling

nice value

File size limit (described in the ulimit(3) function)

Attached shared memory segments (described in the shmat(2) function)

Attached mapped file segments (described in the shmat(2) system call)

All mapped regions with the same protection and sharing mode as in the parent process

Per-process resource limits

/proc attributes, if the inherit flag is set by passing PIOCSFORU to ioctl

The new child of a fork() function inherits policy and priority settings under the SCHED_FIFO, SCHED_RR, and SCHED_OTHER scheduling policies.

3.1.1.4    Errors

For the fork() function, the operating system detects the conditions and returns the corresponding errno value for [ENOMEM].

3.1.2    Execute a File

3.1.2.2    Description

On the operating system, when constructing a pathname that identifies a new process image file, if the file argument does not contain a slash and the PATH environment variable is not present, the result of the search of directories for the file is defined as follows:

Only the current working directory is searched.

On the operating system, the new process image inherits from the calling process image the following process attributes not defined by POSIX.1:

Table 3-2: Process Image Inherited Characteristics

Process Attributes	References
Semaphore adjust values	semop(2)
Trace flag used during debugging	ptrace(2)
System resource limits	setrlimit(2)
The nice value	nice(3)
Per-process interval time value	reltimer(3)

Under the SCHED_FIFO, SCHED_RR, and SCHED_OTHER scheduling policies, priority and policy settings are not changed on exec() functions.

Upon exec(), the operating system cancels any asynchronous I/O that was directed to a file system file, a terminal device, or a streams device.

On the operating system, if the exec() function fails but the system is able to locate the process image file, the st_atime field is not marked for update.

3.1.2.4    Errors

For the exec() functions, the operating system detects the conditions and returns the corresponding errno value for [ENOMEM].

3.2    Process Termination

3.2.1    Wait for Process Termination

3.2.1.2    Description

If status information is available for two or more child processes, the order in which their status is reported is youngest to oldest, based on beginning time. The wait() function reports the status of the most recent child forked first. The next call to wait() reports the status of the next child, previous in time, based on the beginning time of the children.

On the operating system, wait() and waitpid() return the status of a stopped child process that is being traced.

If a process is interrupted by a signal after calling wait() or waitpid(), the value of stat_loc is determined by the initial value of stat_loc.

3.2.2    Terminate a Process

3.2.2.2    Description

Children of a process terminated by _exit() are assigned the process ID of the initialization process init (which is 1) as their parent process.

Upon exit(), the operating system cancels any asynchronous I/O that was directed to a file system file, a terminal device, or a streams device.

3.3    Signals

The following sections relate to implementation-specific signals.

3.3.1    Signal Concepts

3.3.1.1    Signal Names

The operating system supports the queueing of signals and the passing of application defined values for all signals defined in Tables 3-1, 3-2 and 3-2. The following additional signals beyond those required by POSIX.1 occur in the operating system:

• SIGTRAP

• SIGEMT

• SIGBUS

• SIGSYS

• SIGURG

• SIGIO

• SIGPOLL

• SIGXCPU

• SIGXFSZ

• SIGWINCH

• SIGPROF

• SIGVTALRM

3.3.1.2    Signal Generation and Delivery

On the operating system, if the action associated with a blocked signal is to ignore the signal, and if that signal is generated for the process, the signal is ignored. The signal does not become pending for the process.

On the operating system, if a subsequent occurrence of a pending signal is generated, the signal is not delivered more than once. Realtime signals are queued.

On the operating system, under the following conditions not specified in POSIX.1, signals are generated:

Table 3-3: Additional Signals

Signal Name	Generating Condition
SIGTRAP	Trace trap. This signal indicates that a traced process has stopped. See ptrace(2).
SIGEMT	EMT instruction. This signal is hardware-dependent.
SIGSYS	Bad system call. This signal is sent when an application attempts to call a nonexistent or unimplemented system call.
SIGURG	Urgent I/O condition. This signal indicates that out-of-band data has been received on a socket.
SIGIO, SIGPOLL	Input/Output completion. The SIGIO signal is sent to indicate the completion of asynchronous input or output. SIGPOLL is the streams equivalent of the SIGIO signal.
SIGXCPU	CPU time limit exceeded. This signal is sent when the soft CPU time limit is exceeded. See getrlimit(2) for details.
SIGXFSZ	File size limit exceeded. This signal is sent when a file I/O operation would create a file that is too large. See getrlimit(2) for details.
SIGWINCH	Window size change. When a terminal/window size change occurs, this signal is sent to the terminal's process group so that knowledgeable programs can detect the size change. See tty(7) for details.
SIGPROF	Profiling time alarm. This signal is sent when the ITIMER_PROF timer expires. See getitimer(2) for details.
SIGVTALRM	Process virtual time alarm. This signal is sent when the ITIMER_VIRTUAL time expires. See getitimer(2) for details.

3.3.1.3    Signal Actions

(2) SIG_IGN - ignore signal

(a) After a process ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by the kill() function or the raise() function defined in the C standard, it behaves as follows:

The process is terminated and a core file is produced unless one of the following conditions exists:

• There is no available space to write a core file.

• The user sending the signal is not the owner of the process and the process does not allow read permission to the sending process. Such a situation is typically put in place to protect security sensitive processes like those associated with login su and passwd from exposing security sensitive material in a core file.

(d) If a process sets the action for the SIGCHLD signal to SIG_IGN, the following behavior occurs:

No signal is delivered to the parent process when the child process exits. The child does not enter the zombie state; instead, it is removed immediately from the system. This behavior corresponds to the SA_NOCLDWAIT behavior documented on the sigaction(2) reference page.

(3) pointer to a function - catch signal

(b) If the signal code is not SI_USER, SI_QUEUE, SI_TIMER, SI_ASYNCIO, or SI_MESGQ, si_code is set to one of the values listed on the siginfo (3) reference page or in the file <siginfo.h>. In such a case, the signal is a system-generated or exception signal.

(c) When a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill() or by raise() is caught and the signal handler returns normally, the process returns to the faulting instruction. The cycle repeats unless the signal handler takes some action to prevent that from happening.

(e) If a process establishes a signal-catching function for the SIGCHLD signal while it has a terminated child process for which it has not waited, a SIGCHLD signal is not generated to indicate that the child process has terminated.

3.3.2    Send a Signal to a Process

3.3.2.2    Description

Only processes with appropriate privileges are allowed to send a signal to a process not associated with the current UID. (See Section 2.2.2.4.)

On the operating system, kill( pid , sig) has the following implementation-specific behavior:

• If pid is zero, sig is sent to all processes whose process group ID is equal to the process group ID of the sender, and for which the process has permission to send a signal, excluding the following set of system processes:

  • Any process which has a parent pid of zero

  • Any swapper or pager process

• If pid is -1, the signal specified by the sig parameter is sent to all processes, excluding all kernel-only processes and processes whose parent pid is zero. In addition, if sig is SIGKILL or SIGSTOP, the signal is not sent to the sending process.

• If pid is negative but not -1, sig is not sent to the following set of system processes:

  • Any process which has a parent pid of zero

  • Any swapper or pager process

The operating system provides no extended security controls and imposes no additional restrictions on the sending of signals, including the null signal.

3.3.3    Manipulate Signal Sets

3.3.3.4    Errors

For the sigaddset(), sigdelset(), and sigismember() functions, the operating system detects the condition and does return the corresponding errno value for [EINVAL].

3.3.4    Examine and Change Signal Action

3.3.4.2    Description

Even if SA_SIGINFO is not set in sa_flags, subsequent occurrences of sig are queued if they originate with realtime signals.

3.3.5    Examine and Change Blocked Signals

3.3.5.2    Description

On the operating system, if any of the SIGFPE, SIGILL, or SIGSEGV signals are generated while they are blocked, unless the signal was generated by a call to the kill() function or the raise() function defined by the C Standard, the following behavior occurs:

On reception of a SIGFPE or SIGILL, the process will continue. On reception of a SIGSEGV, the process will hang.

3.4    Timer Operations

The following sections deal with timer operations.

3.4.3    Delay Process Execution

3.4.3.2    Description

If a SIGALRM signal is generated for the calling process during execution of the sleep() function, and if the SIGALRM signal is being ignored or blocked from delivery, sleep() does not return when the SIGALRM signal is scheduled.

If a SIGALRM signal is generated for the calling process during execution of the sleep() function while the SIGALRM signal is blocked, the signal remains pending after the sleep() function returns. If a SIGALRM signal is generated for the calling process during execution of the sleep() function, except as a result of a prior call to the alarm() function, and if the SIGALRM signal is not being ignored or blocked from delivery, the signal has the following effect other than causing the sleep() function to return.

The user established SIGALRM handler is entered as soon as the SIGALRM signal is generated.

If a signal-catching function interrupts the sleep() function and examines or changes the time a SIGALRM is scheduled to be generated, the action associated with the SIGALRM signal, or whether the SIGALRM signal is blocked, the following happens:

The sleep() time is nullified and sleep() returns immediately after the signal handler returns.

If a signal-catching function interrupts the sleep() function and calls the siglongjmp() or longjmp() function to restore an environment saved prior to the sleep() call, the following action associated with the SIGALRM function is taken:

The alarm/sleep time is set to 0 and execution proceeds as if the sleep() function had completed. Any scheduled SIGALRM is cancelled.

If a signal-catching function interrupts the sleep() function and calls the siglongjmp() or longjmp() function to restore an environment saved prior to the sleep() call and the process's signal mask is not restored as part of the environment, any scheduled SIGALRM is cancelled when another signal is received.