HPUX signal[5]
signal in anderen Kapiteln des hpux Handbuch:
signal.3f
signal.2
signal(5) signal(5)
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:
center; lb lb lb lb lf4 c lp-1 i lw(3.5i).
Name Number Notes Meaning _ SIGHUP 01 A hangup
SIGINT 02 A interrupt SIGQUIT 03 A,B quit
SIGILL 04 A,B,C illegal instruction
SIGTRAP 05 A,B,C trace trap SIGABRT 06 A,B software
generated abort; see abort(3C) SIGIOT 06 A,B software generated
signal SIGEMT 07 A,B software generated signal
SIGFPE 08 A,B floating point exception
SIGKILL 09 A,D,E,F kill SIGBUS 10 A,B bus error
SIGSEGV 11 A,B segmentation violation SIGSYS 12 A,B bad
argument to system call SIGPIPE 13 A write on a pipe with no
one to read it SIGALRM 14 A alarm clock; see alarm(2)
SIGTERM 15 A software termination signal
SIGUSR1 16 A user defined signal 1 SIGUSR2 17 A user
defined signal 2 SIGCHLD l8 G death of a child (see WARNINGS
below) SIGCLD l8 G death of a child (see WARNINGS below)
SIGPWR 19 C,G power fail (see WARNINGS below)
SIGVTALRM 20 A virtual timer alarm; see getitimer(2)
SIGPROF 21 A profiling timer alarm; see getitimer(2)
SIGIO 22 G asynchronous I/O signal; see select(2)
SIGWINCH 23 G window size change; see termio(7)
SIGSTOP 24 D,E,H stop SIGTSTP 25 H stop signal
generated from keyboard SIGCONT 26 F,G continue after stop
SIGTTIN 27 H T{ background read attempted from control terminal
T} SIGTTOU 28 H T{ background write attempted to control
terminal T} SIGURG 29 G urgent data arrived on an I/O channel
SIGLOST 30 A file lock lost (NFS file locking)
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.
Hewlett-Packard Company - 1 - HP-UX Release 9.0: August 1992
signal(5) signal(5)
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:
o The effective user ID and the real
user ID of the receiving process
are equal.
o The effective group ID and the real
group ID of the receiving process
are equal.
o 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:
o The file mode is 0666, modified by
the file creation mode mask (see
umask(2)).
o The file user ID is equal to the
effective user ID of the receiving
process.
o The file group ID is equal to the
effective group ID of the receiving
process.
Hewlett-Packard Company - 2 - HP-UX Release 9.0: August 1992
signal(5) signal(5)
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>.
Hewlett-Packard Company - 3 - HP-UX Release 9.0: August 1992
signal(5) signal(5)
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.
Hewlett-Packard Company - 4 - HP-UX Release 9.0: August 1992
signal(5) signal(5)
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
Hewlett-Packard Company - 5 - HP-UX Release 9.0: August 1992
signal(5) signal(5)
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 HP98248 floating-point
accelerator. The value of (code &~ 0x80000000) is the
value of the HP98248 status register. Refer to HP98248
documentation for more detailed information.
other any other value indicates an exception while using the MC
68881 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 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;
Hewlett-Packard Company - 6 - HP-UX Release 9.0: August 1992
signal(5) signal(5)
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>: SVID2, XPG2,
Hewlett-Packard Company - 7 - HP-UX Release 9.0: August 1992