SIGACTION(2)SIGACTION(2)NAMEsigaction - 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);
DESCRIPTIONsigaction 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.
Page 1
SIGACTION(2)SIGACTION(2)
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
Page 2
SIGACTION(2)SIGACTION(2)
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 ALSOblockproc(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
