share/doc/psd/05.sysman/1.3.t

   1 .\" Copyright (c) 1983, 1993
   2 .\"     The Regents of the University of California.  All rights reserved.
   3 .\"
   4 .\" Redistribution and use in source and binary forms, with or without
   5 .\" modification, are permitted provided that the following conditions
   6 .\" are met:
   7 .\" 1. Redistributions of source code must retain the above copyright
   8 .\"    notice, this list of conditions and the following disclaimer.
   9 .\" 2. Redistributions in binary form must reproduce the above copyright
  10 .\"    notice, this list of conditions and the following disclaimer in the
  11 .\"    documentation and/or other materials provided with the distribution.
  12 .\" 3. Neither the name of the University nor the names of its contributors
  13 .\"    may be used to endorse or promote products derived from this software
  14 .\"    without specific prior written permission.
  15 .\"
  16 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  17 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  18 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  19 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  20 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  21 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  22 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  23 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  24 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  25 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  26 .\" SUCH DAMAGE.
  27 .\"
  28 .\"     @(#)1.3.t       8.1 (Berkeley) 6/8/93
  29 .\"
  30 .sh "Signals
  31 .PP
  32 .NH 3
  33 Overview
  34 .PP
  35 The system defines a set of \fIsignals\fP that may be delivered
  36 to a process.  Signal delivery resembles the occurrence of a hardware
  37 interrupt: the signal is blocked from further occurrence,
  38 the current process context is saved, and a new one
  39 is built.  A process may specify
  40 the \fIhandler\fP to which a signal is delivered, or specify that
  41 the signal is to be \fIblocked\fP or \fIignored\fP.  A process may
  42 also specify that a
  43 \fIdefault\fP action is to be taken when signals occur.
  44 .PP
  45 Some signals
  46 will cause a process to exit when they are not caught.  This
  47 may be accompanied by creation of a \fIcore\fP image file, containing
  48 the current memory image of the process for use in post-mortem debugging.
  49 A process may choose to have signals delivered on a special
  50 stack, so that sophisticated software stack manipulations are possible.
  51 .PP
  52 All signals have the same \fIpriority\fP.  If multiple signals
  53 are pending simultaneously, the order in which they are delivered
  54 to a process is implementation specific.  Signal routines execute
  55 with the signal that caused their invocation \fIblocked\fP, but other
  56 signals may yet occur.  Mechanisms are provided whereby critical sections
  57 of code may protect themselves against the occurrence of specified signals.
  58 .NH 3
  59 Signal types
  60 .PP
  61 The signals defined by the system fall into one of
  62 five classes: hardware conditions,
  63 software conditions, input/output notification, process control, or
  64 resource control.
  65 The set of signals is defined in the file \fI<signal.h>\fP.
  66 .PP
  67 Hardware signals are derived from exceptional conditions which
  68 may occur during
  69 execution.  Such signals include SIGFPE representing floating
  70 point and other arithmetic exceptions, SIGILL for illegal instruction
  71 execution, SIGSEGV for addresses outside the currently assigned
  72 area of memory, and SIGBUS for accesses that violate memory
  73 protection constraints.
  74 Other, more cpu-specific hardware signals exist,
  75 such as those for the various customer-reserved instructions on
  76 the VAX (SIGIOT, SIGEMT, and SIGTRAP).
  77 .PP
  78 Software signals reflect interrupts generated by user request:
  79 SIGINT for the normal interrupt signal; SIGQUIT for the more
  80 powerful \fIquit\fP signal, that normally causes a core image
  81 to be generated; SIGHUP and SIGTERM that cause graceful
  82 process termination, either because a user has ``hung up'', or
  83 by user or program request; and SIGKILL, a more powerful termination
  84 signal which a process cannot catch or ignore.
  85 Programs may define their own asynchronous events using SIGUSR1
  86 and SIGUSR2.
  87 Other software signals (SIGALRM, SIGVTALRM, SIGPROF)
  88 indicate the expiration of interval timers.
  89 .PP
  90 A process can request notification via a SIGIO signal
  91 when input or output is possible
  92 on a descriptor, or when a \fInon-blocking\fP operation completes.
  93 A process may request to receive a SIGURG signal when an
  94 urgent condition arises.
  95 .PP
  96 A process may be \fIstopped\fP by a signal sent to it or the members
  97 of its process group.  The SIGSTOP signal is a powerful stop
  98 signal, because it cannot be caught.  Other stop signals
  99 SIGTSTP, SIGTTIN, and SIGTTOU are used when a user request, input
 100 request, or output request respectively is the reason for stopping the process.
 101 A SIGCONT signal is sent to a process when it is
 102 continued from a stopped state.
 103 Processes may receive notification with a SIGCHLD signal when
 104 a child process changes state, either by stopping or by terminating.
 105 .PP
 106 Exceeding resource limits may cause signals to be generated.
 107 SIGXCPU occurs when a process nears its CPU time limit and SIGXFSZ
 108 warns that the limit on file size creation has been reached.
 109 .NH 3
 110 Signal handlers
 111 .PP
 112 A process has a handler associated with each signal.
 113 The handler controls the way the signal is delivered.
 114 The call
 115 .DS
 116 #include <signal.h>
 117
 118 ._f
 119 struct sigvec {
 120         int     (*sv_handler)();
 121         int     sv_mask;
 122         int     sv_flags;
 123 };
 124
 125 sigvec(signo, sv, osv)
 126 int signo; struct sigvec *sv; result struct sigvec *osv;
 127 .DE
 128 assigns interrupt handler address \fIsv_handler\fP to signal \fIsigno\fP.
 129 Each handler address
 130 specifies either an interrupt routine for the signal, that the
 131 signal is to be ignored,
 132 or that a default action (usually process termination) is to occur
 133 if the signal occurs.
 134 The constants
 135 SIG_IGN and SIG_DEF used as values for \fIsv_handler\fP
 136 cause ignoring or defaulting of a condition.
 137 The \fIsv_mask\fP value specifies the
 138 signal mask to be used when the handler is invoked; it implicitly includes
 139 the signal which invoked the handler.
 140 Signal masks include one bit for each signal;
 141 the mask for a signal \fIsigno\fP is provided by the macro
 142 \fIsigmask\fP(\fIsigno\fP), from \fI<signal.h>\fP.
 143 \fISv_flags\fP specifies whether system calls should be
 144 restarted if the signal handler returns and
 145 whether the handler should operate on the normal run-time
 146 stack or a special signal stack (see below).  If \fIosv\fP
 147 is non-zero, the previous signal vector is returned.
 148 .PP
 149 When a signal condition arises for a process, the signal
 150 is added to a set of signals pending for the process.
 151 If the signal is not currently \fIblocked\fP by the process
 152 then it will be delivered.  The process of signal delivery
 153 adds the signal to be delivered and those signals
 154 specified in the associated signal
 155 handler's \fIsv_mask\fP to a set of those \fImasked\fP
 156 for the process, saves the current process context,
 157 and places the process in the context of the signal
 158 handling routine.  The call is arranged so that if the signal
 159 handling routine exits normally the signal mask will be restored
 160 and the process will resume execution in the original context.
 161 If the process wishes to resume in a different context, then
 162 it must arrange to restore the signal mask itself.
 163 .PP
 164 The mask of \fIblocked\fP signals is independent of handlers for
 165 signals.  It delays signals from being delivered much as a
 166 raised hardware interrupt priority level delays hardware interrupts.
 167 Preventing an interrupt from occurring by changing the handler is analogous to
 168 disabling a device from further interrupts.
 169 .PP
 170 The signal handling routine \fIsv_handler\fP is called by a C call
 171 of the form
 172 .DS
 173 (*sv_handler)(signo, code, scp);
 174 int signo; long code; struct sigcontext *scp;
 175 .DE
 176 The \fIsigno\fP gives the number of the signal that occurred, and
 177 the \fIcode\fP, a word of information supplied by the hardware.
 178 The \fIscp\fP parameter is a pointer to a machine-dependent
 179 structure containing the information for restoring the
 180 context before the signal.
 181 .NH 3
 182 Sending signals
 183 .PP
 184 A process can send a signal to another process or group of processes
 185 with the calls:
 186 .DS
 187 kill(pid, signo)
 188 int pid, signo;
 189
 190 killpgrp(pgrp, signo)
 191 int pgrp, signo;
 192 .DE
 193 Unless the process sending the signal is privileged,
 194 it must have the same effective user id as the process receiving the signal.
 195 .PP
 196 Signals are also sent implicitly from a terminal device to the
 197 process group associated with the terminal when certain input characters
 198 are typed.
 199 .NH 3
 200 Protecting critical sections
 201 .PP
 202 To block a section of code against one or more signals, a \fIsigblock\fP
 203 call may be used to add a set of signals to the existing mask, returning
 204 the old mask:
 205 .DS
 206 oldmask = sigblock(mask);
 207 result long oldmask; long mask;
 208 .DE
 209 The old mask can then be restored later with \fIsigsetmask\fP\|,
 210 .DS
 211 oldmask = sigsetmask(mask);
 212 result long oldmask; long mask;
 213 .DE
 214 The \fIsigblock\fP call can be used to read the current mask
 215 by specifying an empty \fImask\fP\|.
 216 .PP
 217 It is possible to check conditions with some signals blocked,
 218 and then to pause waiting for a signal and restoring the mask, by using:
 219 .DS
 220 sigpause(mask);
 221 long mask;
 222 .DE
 223 .NH 3
 224 Signal stacks
 225 .PP
 226 Applications that maintain complex or fixed size stacks can use
 227 the call
 228 .DS
 229 ._f
 230 struct sigstack {
 231         caddr_t ss_sp;
 232         int     ss_onstack;
 233 };
 234
 235 sigstack(ss, oss)
 236 struct sigstack *ss; result struct sigstack *oss;
 237 .DE
 238 to provide the system with a stack based at \fIss_sp\fP for delivery
 239 of signals. The value \fIss_onstack\fP indicates whether the
 240 process is currently on the signal stack,
 241 a notion maintained in software by the system.
 242 .PP
 243 When a signal is to be delivered, the system checks whether
 244 the process is on a signal stack.  If not, then the process is switched
 245 to the signal stack for delivery, with the return from the signal
 246 arranged to restore the previous stack.
 247 .PP
 248 If the process wishes to take a non-local exit from the signal routine,
 249 or run code from the signal stack that uses a different stack,
 250 a \fIsigstack\fP call should be used to reset the signal stack.