SIGNAL(5) SIGNAL(5) NAME signal - base signals SYNOPSIS #include <signal.h> DESCRIPTION A signal is an asynchronous notification of an event. A signal is said to be generated for (or sent to) a process or a thread when the event associated with that signal first occurs. Examples of such events include hardware faults, timer expiration and terminal activity, as well as the invocation of the kill(2), sigqueue(3) or sigsend(2) system calls. In some circumstances, the same event generates signals for multiple processes. A process may request a detailed notification of the source of the signal and the reason why it was generated [see siginfo(5)]. At the time of generation, the system will determine whether the signal is directed at a process or a specific thread within that process. Signals that are naturally associated with a particular thread, such as hardware faults, are directed to the appropriate thread. This is usually due to the signal being generated during the execution of the thread and, moreover, in the context of executing that thread. Signals that are sent to a process tend to be those that are generated asynchronously with respect to the execution of the process. Signals generated by the kill interface or sent as a result of a tty interrupt are examples of signals directed at a process. Each process may specify a system action to be taken in response to each signal sent to it, called the signal's disposition. For multithreaded processes, the disposition is shared by all threads in the process. The set of system signal actions for a process is initialized from that of its parent. Once an action is installed for a specific signal, it usually remains installed until another disposition is explicitly requested by a call to either sigaction(2), signal(2), signal(3B), sigvec(3B) or sigset(2), or until the process execs [see sigaction(2) and set to catch the signal will be set to SIG_DFL. Alternatively, a process may request that the system automatically reset the disposition of a signal to SIG_DFL after it has been caught [see sigaction(2) and A signal is said to be delivered to a process or thread when the appropriate action for the signal is taken. During the time between the generation of a signal and its delivery, the signal is said to be pending [see sigpending(2)]. Ordinarily, this interval cannot be detected by an application. However, a signal can be blocked from delivery to a thread [see sighold(2), sigblock(3) and sigprocmask(2)]. If the action associated with a blocked signal is anything other than to ignore the signal, and if that signal is generated for the process or thread, the signal remains pending until either it is unblocked or the signal's disposition requests that the signal be ignored. Signals generated for the process shall be delivered to exactly one of the threads within the process. The thread must either be executing the sigwait function selecting that signal or it must not be blocking delivery of the signal. If there are no threads in a call to a sigwait function selecting that signal, and if all threads within the process block delivery of the signal, the signal shall remain pending of the process until either a thread calls a sigwait function selecting that signal, a thread unblocks delivery of that signal, or the action associated with the signal is set to ignore the signal. If the signal disposition of a blocked signal requests that the signal be ignored, and if that signal is generated for the process or thread, the signal is discarded immediately upon generation. On IRIX, a pending signal is usually delivered when a thread returns from the kernel. This happens at the end of a system call or at the end of a hardware interrupt. Since the scheduling clock interrupt occurs at a regular 10 msec interval, this means that the latency between the generation of a signal and its delivery can never be more than 10 msec. For real-time application(defined as process with high band non-degrading priority), a generation of a signal always force an immediate signal delivery. Each thread has a signal mask that defines the set of signals currently blocked from delivery to it [see sigprocmask(2) or pthread_sigmask(3P)]. The signal mask for a thread is initialized from the thread that created it. The determination of which action is taken in response to a signal is made at the time the signal is delivered, allowing for any changes since the time of generation. This determination is independent of the means by which the signal was originally generated. The signals currently defined in signal.h are as follows: Name Value Default Event __________________________________________________________________________ SIGHUP 1 Exit Hangup [see termio(7)] SIGINT 2 Exit Interrupt [see termio(7)] SIGQUIT 3 Core Quit [see termio(7)] SIGILL 4 Core Illegal Instruction SIGTRAP 5 Core Trace, Breakpoint, Range Error Divide by Zero, or Overflow Trap SIGABRT 6 Core Abort SIGEMT 7 Core Emulation Trap SIGFPE 8 Core Arithmetic Exception SIGKILL 9 Exit Killed SIGBUS 10 Core Bus Error SIGSEGV 11 Core Segmentation Fault SIGSYS 12 Core Bad System Call SIGPIPE 13 Exit Broken Pipe SIGALRM 14 Exit Alarm Clock SIGTERM 15 Exit Terminated SIGUSR1 16 Exit User Signal 1 SIGUSR2 17 Exit User Signal 2 SIGCHLD 18 Ignore Child Status Changed SIGPWR 19 Ignore Power Fail/Restart SIGWINCH 20 Ignore Window Size Change SIGURG 21 Ignore Urgent Socket Condition SIGPOLL 22 Exit Pollable Event [see streamio(7)] SIGIO 22 Exit input/output possible signal SIGSTOP 23 Stop Stopped (signal) SIGTSTP 24 Stop Stopped (user) [see termio(7)] SIGCONT 25 Ignore Continued SIGTTIN 26 Stop Stopped (tty input) [see termio(7)] SIGTTOU 27 Stop Stopped (tty output) [see termio(7)] SIGVTALRM 28 Exit Virtual Timer Expired SIGPROF 29 Exit Profiling Timer Expired SIGXCPU 30 Core CPU time limit exceeded [see getrlimit(2)] SIGXFSZ 31 Core File size limit exceeded [see getrlimit(2)] SIGCKPT 33 Ignore Checkpoint warning [see cpr(1)] SIGRESTART 34 Ignore Restart warning [see cpr(1)] SIGRTMIN 49 Exit POSIX 1003.1b SIGRTMIN SIGRTMAX 64 Exit POSIX 1003.1b SIGRTMAX IRIX supports all signal numbers between 0 and 64. All signals between 0 and 32 are currently used. POSIX 1003.1b reserves all signals between SIGRTMIN and SIGRTMAX for real-time applications. Even though the kernel does not use any signals between 35 and 64, signal number between 35 and 49 are not guaranteed to be available to user programs in future releases. Further more, the default behavior for signals between 35 and 49 is to exit. No signals beyond 32 are applicable to the Berkeley signal functions because these functions use a fixed 32 bits signal mask as part the programming interface. Higher priority signals are delivered first when multiple unblocked signals are pending in order to prioritize event notifications. On the other hand, a lower priority signal can not preempt a higher priority signal handler. All signals between 0 and 32 are of equal priority but all are at higher priority than signals between SIGRTMIN and SIGRTMAX. Within the range of SIGRTMIN to SIGRTMAX, the lower the signal number the higher the priority of that signal. Using the signal(2), signal(3B), sigset(2), sigvec(3B) or sigaction(2) system call, a process may specify one of three dispositions for a signal: take the default action for the signal, ignore the signal, or catch the signal. Default Action: SIG_DFL A disposition of SIG_DFL specifies the default action. The default action for each signal is listed in the table above and is selected from the following: Exit When it gets the signal, the receiving process is to be abnormally terminated with all the consequences outlined in _exit(2). Core When it gets the signal, the receiving process is to be abnormally terminated with all the consequences outlined in _exit(2). In addition, a ``core image'' of the process is constructed in the current working directory. Stop When it gets the signal, the receiving process is to stop. Ignore When it gets the signal, the receiving process is to ignore it. This is identical to setting the disposition to SIG_IGN. Ignore Signal: SIG_IGN A disposition of SIG_IGN specifies that the signal is to be ignored. Catch Signal: function address A disposition that is a function address specifies that, when it gets the signal, the receiving thread is to execute the signal handler at the specified address. Under IRIX, there are two ways a signal handler can be delivered. If SA_SIGINFO is set in the field sa_flags of the sigaction_t structure during a previous call to the sigaction(2) function for the signal being delivered, the signal handler will be invoked as follows: handler (int sig, siginfo_t *sip, ucontext_t *up); otherwise the signal handler will be invoked as follows: handler (int sig, int code, struct sigcontext *sc); Where handler is the specified signal handler function-name. Due to historic implementations, signal handlers have been defined with zero, one, or three parameters. To avoid source incompatibilities, in C, the prototype for the signal handler has intentionally been left empty. C++ requires a prototype, so a compromise must be made. C++ user's should cast their handler to the type SIG_PF in order to be portable. Please see siginfo(5) and ucontext(5) for more details on the meanings of the passed in parameters of the first form. The second form is the default system behavior. In the second form, code is valid only in the following cases: Condition Signal Code User breakpoint SIGTRAP BRK_USERBP User breakpoint SIGTRAP BRK_SSTEPBP Integer overflow SIGFPE BRK_OVERFLOW Divide by zero SIGFPE BRK_DIVZERO Multiply overflow SIGFPE BRK_MULOVF Invalid virtual address SIGSEGV EFAULT Read-only address SIGSEGV EACCES Read beyond mapped object SIGSEGV ENXIO Autogrow for file failed SIGSEGV ENOSPC Automatic memory lock failed SIGSEGV ENOMEM Too many mappings to a page SIGBUS E2BIG Integer divide by zero, multiply overflow, integer overflow, and range errors are special cases. If the binary is not an IRIX 4 binary and a signal handler is installed for SIGFPE then the SIGFPE handler is called, otherwise SIGTRAP is called. This behavior is included to keep older IRIX 4 and IRIX 5 binaries working, however the correct way to code a handler is to use SIGFPE. The third argument sc of the second form is a pointer to a struct sigcontext (defined in <sys/signal.h>) that contains the processor context at the time of the signal. When the signal handler returns, the receiving thread resumes execution at the point it was interrupted, unless the signal handler makes other arrangements. If an invalid function address is specified, results are undefined. If the disposition has been set with the signal(3B), sigset(2), sigvec(3B) or sigaction(2) function, the signal is automatically blocked by the system while the signal catcher is executing. If a longjmp [see setjmp(3C)] is used to leave the signal catcher, then the signal must be explicitly unblocked by the user [see sigrelse(2), sigprocmask(2), and pthread_sigmask(3P)]. If execution of the signal handler interrupts a blocked system call, the handler is executed and the interrupted system call returns a -1 to the calling thread with errno set to EINTR. However, if the SA_RESTART flag is set the system call will be transparently restarted. NOTES The dispositions of the SIGKILL and SIGSTOP signals cannot be altered from their default values. The system generates an error if this is attempted. The SIGKILL and SIGSTOP signals cannot be blocked. The system silently enforces this restriction. Whenever a process receives a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU signal, regardless of its disposition, any pending SIGCONT signal are discarded. Further more, the process will not act upon any delivered signals other than SIGKILL until a SIGCONT is received. Whenever a process receives a SIGCONT signal, regardless of its disposition, any pending SIGSTOP, SIGTSTP, SIGTTIN, and SIGTTOU signals is discarded. In addition, if the process was stopped, it is continued. When a signal is delivered to a thread, if the action of that signal specifies termination, stop, or continue, all the threads in the process shall be terminated, stopped, or continued, respectively. Processes which are blocked via a blockproc system call will unblock if they receive a signal which is fatal (i.e., a non-job-control signal which the are NOT catching), but will still be stopped if the job of which they are a part is stopped. Only upon restart will they die. Any non-fatal signals received by a blocked process will NOT cause the process to be unblocked (an unblockproc(2) or unblockprocall(2) system call is necessary). SIGPOLL is issued when a file descriptor corresponding to a STREAMS [see intro(2)] file has a ``selectable'' event pending. A process must specifically request that this signal be sent using the I_SETSIG ioctl call. Otherwise, the process will never receive SIGPOLL. If the disposition of the SIGCHLD signal has been set with signal, sigvec or sigset, or with sigaction and the SA_NOCLDSTOP flag has been specified, it will only be sent to the calling process when its children exit; otherwise, it will also be sent when the calling process's children are stopped or continued due to job control. The name SIGCLD is also defined in this header file and identifies the same signal as SIGCHLD. SIGCLD is provided for backward compatibility, new applications should use SIGCHLD. The disposition of signals that are inherited as SIG_IGN should not be changed. A call to signal cancels a pending signal sig except for a pending SIGKILL signal. A call to sigset with a signal handler other than SIG_IGN will automatically allow pending signals for the set signal to come in. SEE ALSO exit(2), getrlimit(2), intro(2), kill(2), pause(2), pthread_kill(3P), pthread_sigmask(3P), sigaction(2), sigaltstack(2), signal(2), sigset(2), wait(2), sigsetops(3C), siginfo(5), ucontext(5) Page 6