SIGNAL(2) — HP-UX
NAME
signal − specify what to do upon receipt of a signal
SYNOPSIS
#include <signal.h>
int (∗signal (sig, func))()
int sig;
int (∗func)(); func(sig [, code, scp ] )
int sig, code;
struct sigcontext ∗scp;
DESCRIPTION
Signal allows the calling process to choose one of three ways to handle the receipt of a specific signal. Sig specifies the signal and func specifies the choice.
Sig can be any one of the following except SIGKILL or SIGSTOP:
SIGHUP01hangup
SIGINT02interrupt
SIGQUIT03∗quit
SIGILL04∗•illegal instruction
SIGTRAP05∗•trace trap
SIGIOT06∗software generated (sent by abort(3C))
SIGEMT07∗software generated
SIGFPE08∗floating point exception
SIGKILL09‡+%kill
SIGBUS10∗bus error
SIGSEGV11∗segmentation violation
SIGSYS12∗bad argument to system call
SIGPIPE13write on a pipe with no one to read it
SIGALRM14alarm clock
SIGTERM15software termination signal
SIGUSR116user defined signal 1
SIGUSR217user defined signal 2
SIGCLD18†death of a child (see WARNINGS below)
SIGPWR19•†power fail (see WARNINGS below)
SIGVTALRM20virtual timer alarm; see getitimer(2)
SIGPROF21profiling timer alarm; see getitimer(2)
SIGIO22†asynchronous I/O signal; see select(2)
SIGWINDOW23†window change or mouse signal; see windowing package
SIGSTOP24‡+#stop
SIGTSTP25#stop signal generated from keyboard
SIGCONT26‡†%continue after stop
SIGTTIN27#background read attempted from control terminal
SIGTTOU28#background write attempted to control terminal
SIGURG29†urgent data arrived on an I/O channel
∗ Indicates that a core dump can be generated.
† Indicates that the action on SIG_DFL is to ignore the signal, rather than terminate the process.
# Indicates that the action on SIG_DFL is to stop rather than terminate the process.
% Indicates that the signal will not be held off by a stopped process.
• Indicates that the signal is not reset when it is caught by signal.
‡ Indicates that the signal cannot be ignored.
+ Indicates that the signal cannot be caught.
See below for details.
Func is assigned one of three values: SIG_DFL, SIG_IGN, or a function address. The actions prescribed by these values follow:
SIG_DFL Terminate process upon receipt of a signal.
For those signals not flagged with a dagger († ) or a pound (#) above, upon receipt of the signal sig, the receiving process is terminated with all of the consequences outlined in exit(2). In addition, if sig is marked with an asterisk above and the following conditions are met, a “core image” (see core(4)) is made 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.
An ordinary file named core exists and is writable or can be created. If the file must be created, it will have the following properties:
a mode of 0666 modified by the file creation mask, see umask(2)
a file owner ID identical to the effective user ID of the receiving process
a file group ID identical to the effective group ID of the receiving process
SIG_DFL (#) Stop process upon receipt of a signal.
For those signals flagged with a pound (#) above, upon receipt of the signal sig, the receiving process is stopped. While a process is stopped, any additional signals (except those marked with a percent (%) above, which are processed immediately) sent to the process are held off until the process is restarted. When the process is restarted, pending signals are processed. When a process whose parent is the initialization process (proc1) stops as the result of receiving the SIGTSTP, SIGTTIN, or SIGTTOU signals, it is sent the SIGKILL signal, which causes the process to terminate.
SIG_DFL (†) Take no action upon receipt of a signal.
For those signals flagged with a dagger (†) above, neither terminate nor stop action is taken.
SIG_IGN Ignore signal.
The signal sig is ignored.
Note: the signals SIGKILL, SIGCONT and SIGSTOP cannot be ignored.
function address Catch signal.
Upon receipt of the signal sig, the receiving process executes the signal-catching function pointed to by func. The signal number sig is passed as the first parameter to the signal-catching function. The HP-UX kernel also passes two additional (optional) parameters to signal handler routines. The complete parameter list for func follows:
sig signal number.
code a word of information usually provided by the hardware.
scp a pointer to the machine-dependent structure sigcontext defined in the include file <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 permissible for code to always be zero, and scp to always be NULL.
The pointer scp is valid only during the context of the signal handler.
Optional parameters can be omitted from the handler parameter list, in which case the handler is exactly compatible with System V UNIX. Truly portable software should not use the optional parameters in signal-catching routines.
Before entering the signal-catching function, the value of func for the caught signal is set to SIG_DFL unless the signal is one of those flagged with a bullet (• ) above.
Upon return from the signal-catching function, the receiving process resumes execution at the point it was interrupted.
When a signal is caught during the execution of system calls such as read(2), write(2), open(2) or ioctl(2) on a slow device (such as a terminal, but not a file), during a pause(2) system call or a wait(2) 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 then returns a −1 to the calling process with errno set to EINTR.
Note: The signals SIGKILL and SIGSTOP cannot be caught.
SIGKILL can be sent by the system if an exec(2) system call is unsuccessful, provided that the original program has already been deleted. When signal is called with func set to SIG_IGN and a signal sig is pending, the pending signal is cleared.
EXAMPLES
The following call to signal sets up a signal handler for the SIGINT signal:
int myhandler();
signal (SIGINT, myhandler);
RETURN VALUE
Upon successful completion, signal returns the previous value of func for the specified signal sig. Otherwise, a value of −1 is returned and errno is set to indicate the error.
ERRORS
Signal fails if one or more of the following is true:
[EINVAL] Sig is an illegal signal number, or is equal to SIGKILL or SIGSTOP.
[EINVAL] An attempt is made to ignore SIGCONT (by default SIGCONT is ignored).
WARNINGS
The following two signals behave differently than those described above:
SIGCLD18†death of a child
SIGPWR19•†power fail
There is no guarantee that, in future releases of the HP-UX system, these signals will continue to behave as described below; they are included only for compatibility with other versions of the UNIX system. Their use in new programs is strongly discouraged.
For these signals, func is assigned one of three values: SIG_DFL, SIG_IGN, or a function address. The actions prescribed by these values follow:
SIG_DFL Ignore signal.
The signal is to be ignored.
SIG_IGN Ignore signal.
The signal is to be ignored. Also, if sig is SIGCLD, the calling process’s child processes will not create zombie processes when they terminate, see exit(2).
function address Catch signal.
If the signal is SIGPWR or SIGCLD, the same action is taken as that described above for func equal to function address. In addition, if signal is called to catch SIGCLD in a process that currently has terminated (zombie) children, a SIGCLD signal is delivered to the process immediately. Thus if the signal-catching function re-installs 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 re-install itself after it has called wait(2) or wait3(2). Otherwise the presence of the child that caused the original signal causes another signal immediately, resulting in infinite recursion.
SIGCLD affects two other system calls (wait(2) and exit(2)) as follows:
wait If the func value of SIGCLD is set to SIG_IGN and a wait is executed, the wait blocks until all of the child processes of the calling processes terminate; it then returns a value of −1 with errno set to ECHILD.
exit If the func value of SIGCLD in the parent process of the exiting process is set to SIG_IGN, the exiting process does not create a zombie process.
When processing a pipeline, the shell makes the last process in the pipeline the parent of the preceding processes. Therefore, a process that can receive data from a pipe should not attempt to catch SIGCLD.
Some implementations do not generate SIGPWR. For systems without non-volatile memory, it is useless. SIGPWR is generated when power is restored and the system has done all necessary re-initialization. Processes re-start by responding to SIGPWR.
DEPENDENCIES
Series 300
The signals SIGSTOP, SIGTSTP, SIGCONT, SIGTTIN, and SIGTTOU are not supported.
The signal SIGPWR is not currently generated.
The code word is always zero for all signals except signal 4 (SIGILL) and signal 8 (SIGFPE). For SIGILL, code has the following values:
| 0 | illegal instruction; | |
| 6 | check instruction; | |
| 7 | TRAPV; | |
| 8 | privilege violation. |
Refer to the MC6800xx 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 HP98248 floating point accelerator. The value of (code &~ 0x8000000) is the value of the HP98248 status register. Refer to the HP98248 documentation for more detailed information.
other
any other value indicates an exception while using the MC68881 or MC68882 floating point coprocessor. The value of code is the value of the MC68881 or MC68882 status register. Refer to the MC68881 documentation for more detailed information.
Series 800
The structure pointer scp is always defined.
The code word is always zero for all signals except signal 4 (SIGILL) and signal 8 (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 the Series 800. 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 handler in the user program, the instruction that caused the trap is re-executed upon return from the handler routine unless program flow is altered by the handler. For example, the longjmp routine (see setjmp(3C)) may 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), kill(2), lseek(2), pause(2), wait(2), abort(3C), setjmp(3C).
Hewlett-Packard Company — May 11, 2021