I would appreciate any donations. Wishlist or send e-mail type donations to maekawa AT daemon-systems.org.

Thank you.


SIGNAL(7)              Miscellaneous Information Manual              SIGNAL(7)

NAME
     signal - signal facilities

DESCRIPTION
     A signal is a system-level notification delivered to a process.  Signals
     may be generated as the result of process activity, by certain user
     inputs, by kernel facilities or subsystems, or sent programmatically by
     other processes or by users.  There is a small fixed set of signals, each
     with a symbolic name and a number.  For historical reasons many of the
     numbers are ``well-known values'', which are in practice the same on all
     implementations and realistically can never be changed.  (Nonetheless,
     compiled code should always use only the symbolic names.)  Many/most
     signals also have specific semantics, both in how they can be generated
     and in their effects.  Some are special cases in ways that have quite
     far-reaching consequences.

     When a signal is posted ("sent") to a process, in general any of several
     things can happen.  If the process has elected to ignore the signal, it
     is discarded and nothing happens.  (Some signals may not be ignored,
     however.)  If the process has elected to block the signal temporarily,
     delivery is postponed until the process later unblocks that signal.
     Otherwise, the signal is delivered, meaning that whatever the process is
     doing is interrupted in order to react to the signal.  (Note that
     processes that are waiting in the kernel must unwind what they are doing
     for signals to be delivered.  This can sometimes be expensive.  See
     sigaction(2) for further information.)

     If the process has elected to catch the signal, which means that the
     process has installed a handler to react to the signal in some process-
     specific way, the kernel arranges for the process's handler logic to be
     invoked.  This is always done in a way that allows the process to resume
     if desired.  (Note, however, that some signals may not be caught.)
     Otherwise, the default action for the signal is taken.  For most signals
     the default action is a core dump.  See the table below.  Note that the
     term delivery is also used for the specific process of arranging for a
     signal handler to be invoked.

     In general, signals are delivered as soon as they are posted.  (Some
     delays may occur due to scheduling.)  However, in some cases a process
     that has been sleeping in the kernel may need to do slow things as part
     of unwinding its state; this can sometimes lead to human-perceptible
     delays.

     Also, some sleep states within the kernel are uninterruptible meaning
     that signals posted will have no effect until the state clears.  These
     states are supposed to be short-term only, but sometimes kernel bugs make
     this not the case and one can end up with unkillable processes.  Such
     processes appear in state "D" in ps(1).  In general the only way to get
     rid of them is to reboot.  (However, when the "wchan" reported is
     "tstile", it means the process is waiting for some other process to
     release resources; sometimes if one can find and kill that process the
     situation is recoverable.)

   Signal list
     The following signals are defined in NetBSD:

     SIGHUP           Hangup
     SIGINT           Interrupt
     SIGQUIT          Quit
     SIGILL           Illegal instruction
     SIGTRAP          Trace/BPT trap
     SIGABRT          Abort trap
     SIGEMT           EMT trap
     SIGFPE           Floating point exception
     SIGKILL          Killed
     SIGBUS           Bus error
     SIGSEGV          Segmentation fault
     SIGSYS           Bad system call
     SIGPIPE          Broken pipe
     SIGALRM          Alarm clock
     SIGTERM          Terminated
     SIGURG           Urgent I/O condition
     SIGSTOP          Suspended (signal)
     SIGTSTP          Suspended
     SIGCONT          Continued
     SIGCHLD          Child exited
     SIGTTIN          Stopped (tty input)
     SIGTTOU          Stopped (tty output)
     SIGIO            I/O possible
     SIGXCPU          CPU time limit exceeded
     SIGXFSZ          File size limit exceeded
     SIGVTALRM        Virtual timer expired
     SIGPROF          Profiling timer expired
     SIGWINCH         Window size changed
     SIGINFO          Information request
     SIGUSR1          User defined signal 1
     SIGUSR2          User defined signal 2
     SIGPWR           Power fail/restart

     These are numbered 1 to 32.  (There is no signal 0; 0 is a reserved value
     that can be used as a no-op with some signal operations.)

     Detailed descriptions of these signals follow.

     SIGHUP (Hangup)
          This signal is generated by the tty driver tty(4) to indicate a
          hangup condition on a process's controlling terminal: the user has
          disconnected.  Accordingly, the default action is to terminate the
          process.  This signal is also used by many daemons, such as
          inetd(8), as a cue to reload configuration.  The number for SIGHUP
          is 1, which is quite well known.

     SIGINT (Interrupt)
          This signal is generated by the tty driver tty(4) when the user
          presses the interrupt character, normally control-C.  The default
          action is to terminate the process.  The number for SIGINT is 2.

     SIGQUIT (Quit)
          This signal is generated by the tty driver tty(4) when the user
          presses the quit character, normally control-backspace.  The default
          action is to terminate the process and dump core.  The number for
          SIGQUIT is 3.

     SIGILL (Illegal instruction)
          This signal is generated synchronously by the kernel when the
          process executes an invalid instruction.  The default action is to
          terminate the process and dump core.  Note: the results of executing
          an illegal instruction when SIGILL is blocked or ignored are
          formally unspecified.  The number for SIGILL is 4.

     SIGTRAP (Trace/BPT trap)
          This signal is used when a process is being traced (see ptrace(2))
          to indicate that the process has stopped at a breakpoint or after
          single-stepping.  It is normally intercepted by the debugger and not
          exposed to the debuggee.  The default action is to terminate the
          process and dump core.  The number for SIGTRAP is 5.

     SIGABRT (Abort trap)
          This signal is generated when the abort(3) standard library function
          is called.  The default action is to terminate the process and dump
          core.  The number for SIGABRT is 6.  This number was also formerly
          used for SIGIOT, which is no longer defined.

     SIGEMT (EMT trap)
          In theory this signal is generated when an instruction needs to be
          emulated.  The default action is to terminate the process and dump
          core.  The number for SIGEMT is 7.

     SIGFPE (Floating point exception)
          This signal is generated when an invalid floating point operation is
          detected by hardware or by a soft-float library.  The default action
          is to terminate the process and dump core.  The number for SIGFPE is
          8.

     SIGKILL (Killed)
          This signal cannot be caught or ignored.  The (unconditional) action
          is to terminate the process.  It is most often sent by system
          administrators, but is also generated by the kernel in response to
          running completely out of memory and swap space.  Note that because
          many processes need to perform cleanup before exiting, it is usually
          best (as a user or administrator) to not deploy SIGKILL until a
          process has failed to respond to other signals.  The number for
          SIGKILL is 9, which is extremely well known.

     SIGBUS (Bus error)
          This signal is generated synchronously by the kernel when the
          process performs certain kinds of invalid memory accesses.  The most
          common cause of SIGBUS is an unaligned memory access; however, on
          some architectures it may cover other memory conditions, such as
          attempts to access memory belonging to the kernel.  The default
          action is to terminate the process and dump core.  Note: the results
          of performing such invalid accesses when SIGBUS is blocked or
          ignored are formally unspecified.  The number for SIGBUS is 10.

     SIGSEGV (Segmentation fault)
          This signal is generated synchronously by the kernel when the
          process attempts to access unmapped memory, or access memory in a
          manner that the protection settings for that memory region do not
          permit.  On some architectures other assorted permission or
          protection errors also yield SIGSEGV.  On NetBSD, passing invalid
          pointers to system calls will yield failure with EFAULT but not also
          SIGSEGV.  The default action is to terminate the process and dump
          core.  Note: the results of an invalid memory access when SIGSEGV is
          blocked or ignored are formally unspecified.  The number for SIGSEGV
          is 11, which is very well known.

     SIGSYS (Bad system call)
          This signal is generated by the kernel, in addition to failing with
          ENOSYS, when a system call is made using an invalid system call
          number.  The default action is to terminate the process and dump
          core.  The number for SIGSYS is 12.

     SIGPIPE (Broken pipe)
          This signal is generated by the kernel, in addition to failing with
          EPIPE, when a write(2) call or similar is made on a pipe or socket
          that has been closed and has no readers.  The default action is to
          terminate the process.  The number for SIGPIPE is 13.

     SIGALRM (Alarm clock)
          This signal is generated by the kernel when a real-time timer
          expires.  See alarm(3), setitimer(2), and timer_settime(2).  The
          default action is to terminate the process.  The number for SIGALRM
          is 14.

     SIGTERM (Terminated)
          This signal is the default signal sent by kill(1) and represents a
          user or administrator request that a program shut down.  It is sent
          to all processes as part of the shutdown(8) procedure.  The default
          action is to terminate the process.  The number for SIGTERM is 15.

     SIGURG (Urgent I/O condition)
          This signal is generated when an ``urgent condition'' exists on a
          socket.  In practice this means when tcp(4) out-of-band data has
          arrived.  The default action is to do nothing.  The number for
          SIGURG is 16.

     SIGSTOP (Suspended (signal))
          This signal cannot be caught or ignored.  The (unconditional) action
          is to stop the process.  Note that like with SIGKILL (and for
          similar reasons) it is best to not send this signal until a process
          has failed to respond to SIGTSTP.  It can also be used by processes
          to stop themselves after catching SIGTSTP.  A process that is
          explicitly stopped will not run again until told to with SIGCONT.
          The number for SIGSTOP is 17.

     SIGTSTP (Suspended)
          This signal is generated by the tty driver tty(4) when the user
          presses the stop character, normally control-Z.  The default action
          is to stop the process.  The number for SIGTSTP is 18.

     SIGCONT (Continued)
          This signal is generated by the job-control feature of shells to
          manage processes.  It causes the target process to start executing
          again after previously being stopped.  This happens as a magic extra
          effect before the signal is actually delivered.  The default action
          when the signal is delivered is to do nothing (else).  The number
          for SIGCONT is 19.

     SIGCHLD (Child exited)
          This signal is generated by the kernel when one of a process's
          immediate children exits and can be waited for using one of the
          wait(2) family of functions.  The default action is to do nothing.
          As a special case hack, if SIGCHLD is ignored (not merely blocked)
          when a process is created, it is detached from its parent
          immediately so it need not be waited for.  This behavior is a System
          V historic wart, implemented in NetBSD only for compatibility.  It
          is not portable, not recommended, and should not be used by new
          code.  The number for SIGCHLD is 20.  This signal was spelled SIGCLD
          in old System V versions and today many systems provide both
          spellings.

     SIGTTIN (Stopped (tty input))
          This signal is generated by the tty driver tty(4) when a process
          that is not in the foreground of its controlling terminal attempts
          to read from this terminal.  The default action is to stop the
          process.  The number for SIGTTIN is 21.

     SIGTTOU (Stopped (tty output))
          This signal is generated by the tty driver tty(4) when a process
          that is not in the foreground of its controlling terminal attempts
          to write to this terminal, if the terminal is configured
          accordingly, which is not the default.  (See termios(4).) The
          default action is to stop the process.  The number for SIGTTOU is
          22.

     SIGIO (I/O possible)
          This signal is sent by the kernel when I/O becomes possible on a
          file handle opened for asynchronous access with O_ASYNC.  See
          open(2) and fcntl(2).  The default action is to do nothing.  The
          number for SIGIO is 23.

     SIGXCPU (CPU time limit exceeded)
          This signal is sent by the kernel when the amount of CPU time
          consumed exceeds the configured limit.  See setrlimit(2) and the
          ulimit and rlimit builtins of sh(1) and csh(1) respectively.  The
          default action is to terminate the process.  The number for SIGXCPU
          is 24.

     SIGXFSZ (File size limit exceeded)
          This signal is sent by the kernel when a write causes the size of a
          file to exceed the configured limit.  See setrlimit(2) and the
          ulimit and rlimit builtins of sh(1) and csh(1) respectively.  The
          default action is to terminate the process.  The number for SIGXFSZ
          is 25.

     SIGVTALRM (Virtual timer expired)
          This signal is generated by the kernel when a virtual-time (process
          execution time) timer expires.  See setitimer(2) and
          timer_settime(2).  The default action is to terminate the process.
          The number for SIGVTALRM is 26.

     SIGPROF (Profiling timer expired)
          This signal is generated by the kernel when a profiling timer
          expires.  See setitimer(2) and timer_settime(2).  The default action
          is to terminate the process.  The number for SIGPROF is 27.

     SIGWINCH (Window size changed)
          This signal is generated by the tty driver tty(4) when the stored
          window size of the process's controlling terminal has changed.  The
          default action is to do nothing.  The number for SIGWINCH is 28.

     SIGINFO (Information request)
          This signal is generated by the tty driver tty(4) when the user
          presses the status request character, normally control-T.  The
          default action is to do nothing.  The number for SIGINFO is 29.

     SIGUSR1 (User defined signal 1)
          This signal is not generated by the system and is made available for
          applications to use for their own purposes.  Many daemons use it for
          restart or reload requests of various types.  The default action is
          to terminate the process.  The number for SIGUSR1 is 30.

     SIGUSR2 (User defined signal 2)
          This signal is not generated by the system and is made available for
          applications to use for their own purposes.  The default action is
          to terminate the process.  The number for SIGUSR2 is 31.

     SIGPWR (Power fail/restart)
          This signal is notionally sent by the kernel or by a privileged
          monitor process when an external power failure is detected, and
          again when power has been restored.  Currently NetBSD does not in
          fact send SIGPWR, although it is possible to prepare a custom
          configuration for powerd(8) that does so.  The default action is to
          do nothing.  The number for SIGPWR is 32.

   Shell Interface
     Signals may be sent with the kill(1) utility, either by number or the
     symbolic name without the ``SIG'' part.  This utility is built into many
     shells to allow addressing job control jobs.

   Program Interface
     In C code signals may be sent using raise(3), kill(2), pthread_kill(3),
     and some other related functions.

     Signals may be caught or ignored using sigaction(2) or the simpler
     signal(3), and blocked using sigprocmask(2).

STANDARDS
     The SIGTRAP, SIGEMT, SIGBUS, SIGSYS, SIGURG, SIGIO, SIGXCPU, SIGXFSZ,
     SIGVTALRM, SIGPROF, SIGWINCH, and SIGINFO signals are long-existing
     Berkeley extensions, available on most BSD-derived systems.  The SIGPWR
     signal comes from System V.

     The remaining signals conform to IEEE Std 1003.1-1990 ("POSIX.1").

HISTORY
     SIGPWR was introduced in NetBSD 1.4.

NetBSD 8.0                       July 9, 2016                       NetBSD 8.0