SIGNAL(2) SIGNAL(2)
NAME
signal, kill - receive and send signals
SYNOPSIS
#include <signal.h>
SIG_TYP signal(sig, func)
SIG_TYP func;
int kill(pid, sig)
DESCRIPTION
A signal is generated by some abnormal event initiated by a
user at a terminal (quit, interrupt), by a program error
(bus error, etc.), or by kill in another process. Normally,
most signals cause termination of the receiving process, but
signal allows them either to be ignored or to be caught by
interrupting to a specified function. The following signal
names are defined in
SIGHUP 1 hangup
SIGINT 2 interrupt
SIGQUIT 3* quit
SIGILL 4* illegal instruction (not reset when caught)
SIGTRAP 5* trace trap (not reset when caught)
SIGIOT 6* IOT instruction
SIGEMT 7* EMT instruction
SIGFPE 8* floating point exception
SIGKILL 9 kill (cannot be caught or ignored)
SIGBUS 10* bus error
SIGSEGV 11* segmentation violation
SIGSYS 12* bad argument to system call
SIGPIPE 13 write on a pipe with no one to read it
SIGALRM 14 alarm clock
SIGTERM 15 software termination signal
16 unassigned
SIGSTOP 17+ stop (cannot be caught or ignored)
SIGCONT 19# continue a stopped process
SIGCHLD 20# child has stopped or exited
* places core image in file core if not caught or
ignored
+ suspends process until SIGCONT or PIOCRUN; see
proc(4)
# ignored if not caught
Signals 1 through NSIG-1, defined in the include file,
exist. Those not listed above have no conventional meaning
in this system. (Berkeley systems use 1-15 and 17-25.)
SIGNAL(2) SIGNAL(2)
Signal specifies how signal sig will be handled. If func is
SIG_DFL, the default action listed above is reinstated. If
func is SIG_IGN, the signal will be ignored. Otherwise,
when the signal occurs, it will be caught and a function,
pointed to by func, will be called. The type of pointer func
is SIG_TYP:
typedef int (*SIG_TYP)();
It must point to a function such as,
int catcher(sig) { ... }
which will be called with a signal number as argument. A
return from the catcher function will continue the process
at the point it was interrupted.
Except as indicated, a signal is reset to SIG_DFL after
being caught. Thus if it is desired to catch every such
signal, the catching routine must issue another signal call.
When a caught signal occurs during certain system calls, the
call terminates prematurely. In particular this can occur
during read(2) or write on a slow device (like a typewriter,
but not a disk), and during pause and wait; see alarm(2) and
exit(2). The interrupted system call will return error
EINTR. The user's program may then, if it wishes, re-
execute the call.
Signal returns the previous (or initial) value of func for
the particular signal.
After a fork(2) the child inherits all signal settings.
Exec(2) resets all caught signals to default action.
Kill sends signal sig to the process specified by process id
pid. Signal 0 has no effect on the target process and may be
used to test the existence of a process. The success of
sending a signal is independent of how the receiving process
treats the signal.
The effective userid of the sending process must be either 0
or the effective userid of the receiving process.
If pid is 0, the signal is sent to all other processes in
the sender's process group; see stream(4).
If pid is -1, and the user is the super-user, the signal is
broadcast universally except to processes 0 (scheduler), 1
(initialization) and 2 (pageout); see init(8). If pid is
less than -1, it is negated and taken as a process group
whose members should receive the signal.
Processes may send signals to themselves.
SIGNAL(2) SIGNAL(2)
FILES
SEE ALSO
kill(1), setjmp(3), stream(4)
DIAGNOSTICS
signal: EINVAL
kill: EINVAL, EPERM, ESRCH
BUGS
The reason for a trap should be distinguishable by extra
arguments to the signal handler.
If a repeated signal arrives before the last one can be
reset, there is no chance to catch it.
For historical reasons, the return value of a catcher func-
tion is int; it is void in ANSI standard C.