SIGACTION(2) SIGACTION(2) NAME sigaction - software signal facilities (POSIX) SYNOPSIS #include <signal.h> C: struct sigaction { int sa_flags; union { void (*sa_handler)(); void (*sa_sigaction)(int, siginfo_t *, void *); } sigset_t sa_mask; }; C++: struct sigaction { int sa_flags; union { void (*sa_handler)(int); void (*sa_sigaction)(int, siginfo_t *, void *); } sigset_t sa_mask; }; int sigaction(int sig, struct sigaction *act, struct sigaction *oact); DESCRIPTION sigaction specifies and reports on the way individual signals are to be handled in the calling process. sig specifies the signal and can be assigned any of the signals specified in signal(5). If act is non-zero, it points to a structure specifying the new action to be taken when delivering sig. If oact is non-zero, the previous handling information for the signal is returned to the user. In this way (a NULL act and a non-NULL oact) the user can enquire as to the current handling of a signal without changing it. If both act and oact are NULL, sigaction will return EINVAL if sig is an invalid signal (else 0), allowing an application to dynamically determine the set of signals supported by the system. If the SA_SIGINFO flag is clear in sa_flags then sa_handler specifies the disposition of the signal and may take any of the values specified in signal(5). If the SA_SIGINFO flag is set in sa_flags then sa_sigaction specifies the disposition of the signal and may take a pointer to a function. sa_mask specifies a set of signals to be blocked while the signal handler is active. On entry to the signal handler, that set of signals is added to the set of signals already being blocked when the signal is delivered. In addition, the signal that caused the handler to be executed will also be blocked, unless the SA_NODEFER flag has been specified. Keep in mind that SA_NODEFER is superseded by sa_mask so that if SA_NODEFER is set but the same signal is specified in sa_mask, the signal will still be blocked. SIGSTOP and SIGKILL cannot be blocked (the system silently enforces this restriction). The user constructs this mask via the routines described in sigsetops(3). The sa_flags field specifies a set of flags used to modify the delivery of the signal. It is formed by a logical OR of any of the following values: SA_ONSTACK If set and the signal is caught and an alternate signal stack has been declared with sigaltstack(2), the signal is delivered to the calling process on that stack. Otherwise, the signal is delivered on the same stack as the main program. SA_RESETHAND If set and the signal is caught, the disposition of the signal is reset to SIG_DFL (SIGILL, SIGTRAP, and SIGPWR cannot be automatically reset when delivered; the system silently enforces this restriction). SA_NODEFER If set and the signal is caught, the signal will not be automatically blocked by the kernel while it is being caught. SA_RESTART If set and the signal is caught, a system call that is interrupted by the execution of this signal's handler is transparently restarted by the system. Otherwise, that system call returns an EINTR error. SA_SIGINFO If set and the signal is caught, sig is passed as the first argument to the signal-catching function. If the second argument is not equal to NULL, it points to a siginfo_t structure containing the reason why the signal was generated [see siginfo(5)]; the third argument points to a ucontext_t structure containing the receiving process's context when the signal was delivered [see ucontext(5)]. If cleared and the signal is caught, the first argument is also the signal number but the second argument is the signal code identifying the cause of the signal. The third argument points to a sigcontext_t structure containing the receiving process's context when the signal was delivered. This is the default behavior (see signal(5) for more details). Additionally, when SA_SIGINFO is set for a signal, multiple occurrences of that signal will be queued for delivery in FIFO order (see sigqueue(3) for a more detailed explanation of this concept), if those occurrences of that signal were generated using sigqueue(3). SA_NOCLDWAIT If set and sig equals SIGCHLD, the system will not create zombie processes when children of the calling process exit. If the calling process subsequently issues a wait(2), it blocks until all of the calling process's child processes terminate, and then returns a value of -1 with errno set to ECHILD. SA_NOCLDSTOP If set and sig equals SIGCHLD, sig will not be sent to the calling process when its child processes stop or continue. sigaction will fail and no new signal handler will be installed if one of the following occurs: [EFAULT] Either act or oact points to memory that is not a valid part of the process address space. [EINVAL] sig is not a valid signal number. [EINVAL] An attempt is made to ignore or supply a handler for SIGKILL or SIGSTOP. SEE ALSO blockproc(2), kill(2), signal(2), sigprocmask(2), sigpending(2), sigsuspend(2), sigwait(2), sigsetjmp(3), sigset(2), setrlimit(2), ulimit(2), wait(2), sigsetops(3), sigvec(3B), signal(5). DIAGNOSTICS A 0 value indicates that the call succeeded. A -1 return value indicates an error occurred and errno is set to indicate the reason. WARNINGS Signals raised by any instruction in the instruction stream, including SIGFPE, SIGILL, SIGEMT, SIGBUS, and SIGSEGV, will cause infinite loops if their handler returns, or the action is set to SIG_IGN. This is because the exception PC at the time of the signal points to the instruction that raised the exception or signal, and resuming the process will re-execute that same instruction. The POSIX signal routines (sigaction(2), sigpending(2), sigprocmask(2), sigsuspend(2), sigsetjmp(3)), and the 4.3BSD signal routines (sigvec(3B), signal(3B), sigblock(3B), sigpause(3B), sigsetmask(3B)) must NEVER be used with signal(2) or sigset(2). In multithreaded processes, sigaction cannot be used to predictably affect another thread waiting for the affected signals via sigwait. Page 3