NAME

signal − Description of signals

DESCRIPTION

HP-UX supports multiple signal interfaces (see sigaction(2), signal(2), sigvector(2), bsdproc(2), and sigset(2V)) that allow a process to specify the action taken upon receipt of a signal. All supported signal interfaces require specification of a signal, as designated by the Name and Number shown below.  Signal specification can be any of the following except SIGKILL or SIGSTOP, which cannot be caught or ignored:

The letters in the Notes column in the table above indicate the action taken when the signal is received, and any special conditions on its use:

A The default action is to terminate the process. 

B The default action of terminating the process also generates a core image file if possible. 

C The action is not reset to SIG_DFL before calling the signal-catching function. 

D The signal cannot be ignored. 

E The signal cannot be caught. 

F The signal will not be held off from a stopped process. 

G The default action is to ignore the signal. 

H The default action is to stop the process. 

All signal interfaces allow specification of an action that determines what to do upon the receipt of a signal, and should be one of the following:

SIG_DFL Execute the default action, which varies depending on the signal as described above:

A Terminate the receiving process with all of the consequences outlined in exit(2).

B If following conditions are met, generate a core image file (see core(4)) in the current working directory of the receiving process:

• The effective user ID and the real user ID of the receiving process are equal. 

• The effective group ID and the real group ID of the receiving process are equal. 

• A regular file named core does not exist and can be created, or exists and is writable. 

If the file is created, it has the following properties:

• The file mode is 0666, modified by the file creation mode mask (see umask(2)).

• The file user ID is equal to the effective user ID of the receiving process. 

• The file group ID is equal to the effective group ID of the receiving process. 

G Ignore the signal.  Do not terminate or stop the receiving process. 

H Stop the receiving process.  While a process is stopped, any additional signals sent to the process are suspended until the process is restarted (except those marked with Note F above, which are processed immediately).  However, when the process is restarted, pending signals are processed.  When a process that is in an orphaned process group (see glossary(9)) receives a SIGTSTP, SIGTTIN, or SIGTTOU signal, the process is not stooped because a process in an orphaned process group is not allowed to stop.  Instead, a SIGHUP signal is sent to the process, and the SIGTSTP, SIGTTIN, or SIGTTOU is discarded. 

SIG_IGN Ignore the signal. 
When one of the supported signal interface routines is used to set the action of a signal to SIG_IGN and an instance of the signal is pending, the pending signal is cleared. 

D Signals marked with Note D above cannot be ignored. 

address Catch the signal. 
Upon receipt of the signal, if signal() is used to set the action, reset the action for the signal caught to SIG_DFL (except signals marked with Note C). Then, call the signal-catching function to which address points, and resume executing the receiving process at the point where it was interrupted.  Signal interface routines other than signal() normally do not reset the action for the signal caught.  However, sigaction() and sigvector() provide a way of specifying this behavior (see sigaction(2) or sigvector(2)).

The signal-catching function is called with the following three parameters:

sig The signal number. 

code A word of information usually provided by the hardware. 

scp A pointer to the machine-dependent structure sigcontext defined in <signal.h>. 

Depending on the value of sig, code can be zero and/or scp can be NULL.  The meanings of code and scp and the conditions determining when they are other than zero or NULL are implementation-dependent (see DEPENDENCIES below).  It is possible for code to always be zero, and scp to always be NULL. 

The pointer scp is valid only during the context of the signal-catching function. 

Optional parameters can be omitted from the signal-catching function parameter list, in which case the signal-catching function is exactly compatible with UNIX System V.  Truly portable software should not use the optional parameters in signal-catching routines. 

Upon return from the signal-catching function, the receiving process resumes execution at the point where it was interrupted. 

When a signal is caught during the execution of system calls such as read(), write(), open(), or ioctl() on a slow device (such as a terminal, but not a file), during a pause() system call or a wait() system call that does not return immediately because a previously stopped or zombie process already exists, the signal-catching function is executed and the interrupted system call returns a −1 to the calling process with errno set to EINTR. 

C If the signal is marked with Note C above, the action is not reset to SIG_DFL before calling the signal-catching function.  Furthermore, the action is not reset if any signal interface routine other than signal() was used to set the action.  See the description of signal catching above. 

E If the signal is marked with Note E above, the signal cannot be caught. 

When any stop signal (SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) is generated for a process, pending SIGCONT signals for that process are discarded.  Conversely, when SIGCONT is generated for a process, all pending stop signals for that process are discarded.  When SIGCONT is generated for a stopped process, the process is continued, even if the SIGCONT signal is blocked or ignored.  If SIGCONT is blocked and not ignored, the process remains pending until it is either unblocked or a stop signal is generated. 

SIGKILL is sent by the system if an exec() system call is unsuccessful and the original program has already been deleted. 

WARNINGS

The signals SIGCLD and SIGPWR behave differently than those described above. 

The actions for these signals is modified as follows:

SIGCLD Setting the action for SIGCLD to SIG_IGN in a parent process prevents exiting children of the calling process from creating a zombie process.  If the parent process executes the wait() function, the calling process blocks until all of the child processes of the calling processes terminate.  The wait() function then returns a value of −1 with errno set to ECHILD (see wait(2)).

If one of the signal interface routines is used to set the action for SIGCLD to be caught (that is, a function address is supplied) in a process that currently has terminated (zombie) children, a SIGCLD signal is delivered to the parent process immediately.  Thus, if the signal-catching function reinstalls itself, the apparent effect is that any SIGCLD signals received due to the death of children while the function is executing are queued and the signal-catching function is continually reentered until the queue is empty.  Note that the function must reinstall itself after it calls wait(), wait3(), or waitpid().  Otherwise the presence of the child that caused the original signal causes another signal immediately, resulting in infinite recursion. 

When processing a pipeline, the Bourne shell (see sh-bourne(1)) makes the last process in the pipeline the parent of the preceding processes. Job control shells including C shell, Korn shell and the POSIX shell (see csh(1), ksh(1), and sh-posix(1)) make the shell itself the parent of all processes in the pipeline. Therefore, a process that can receive data from a pipe should not attempt to catch SIGCLD. 

SIGPWR The SIGPWR signal is sent to all processes after a power interruption when power is restored and the system has done all necessary reinitialization.  Processes restart by catching (or ignoring) SIGPWR. 

Applications that wish to recover from power failures should catch SIGPWR and take whatever necessary steps to reinitialize itself. 

Some implementations do not generate SIGPWR.  Only systems with nonvolatile memory can recover from power failures. 

DEPENDENCIES

Series 300/400

The SIGPWR signal is not currently generated. 

The code word is always zero for all signals except SIGILL and SIGFPE.  For SIGILL, code has the following values:

0 Illegal instruction;

6 Check instruction;

7 TRAPV;

8 Privilege violation. 

Refer to the MC680xx processor documentation for more detailed information about the meaning of the SIGILL errors. 

For SIGFPE, code has the following values:

0 Software floating point exception;

5 Integer divide-by-zero. 

0x8xxxxxxx
Any value with the high-order bit set indicates an exception while using the HP 98248 floating-point accelerator.  The value of (code &~ 0x80000000) is the value of the HP 98248 status register.  Refer to HP 98248 documentation for more detailed information. 

other any other value indicates an exception while using the MC 68881 or MC 68882 floating point coprocessor.  The value of code is the value of the MC 68881 or MC 68882 status register.  Refer to the MC 68881 documentation for more detailed information. 

Series 700

The signal SIGPWR is not currently generated. 

Series 700/800

The structure pointer scp is always defined. 

The code word is always zero for all signals except SIGILL and SIGFPE.  For SIGILL, code has the following values:

 8 Illegal instruction trap;

 9 Break instruction trap;

10 Privileged operation trap;

11 Privileged register trap. 

For SIGFPE, code has the following values:

12 Overflow trap;

13 Conditional trap;

14 Assist exception trap;

22 Assist emulation trap. 

Refer to the Series 800 processor documentation provided with your system for more detailed information about the meaning of these errors. 

The Instruction Address Offset Queue (program counter) is not advanced when a trap occurs on Series 800 systems.  If a signal generated by a hardware trap is masked or has its signal action set to SIG_IGN, the program loops infinitely since the instruction causing the trap is re-executed, causing the trap again.  If the signal is received by a signal-catching function in the user program, the instruction that caused the trap is re-executed upon return from the signal-catching function unless program flow is altered by the signal-catching function.  For example, the longjmp() routine (see setjmp(3C)) can be called. Using longjmp() ensures software portability across different hardware architectures. 

AUTHOR

signal was developed by HP, AT&T, and the University of California, Berkeley. 

SEE ALSO

kill(1), init(1M), bsdproc(2), exit(2), kill(2), lseek(2), pause(2), sigaction(2), signal(2), sigvector(2), wait(2), sigset(2V), abort(3C), setjmp(3C). 

STANDARDS CONFORMANCE

<signal.h>:

Hewlett-Packard Company  —  HP-UX Release 9.0: August 1992