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