sigaction

sigaction

===================================================================================
from:

The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition
Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved.

---

NAME

sigaction - examine and change a signal action

SYNOPSIS

[] #include <>

int sigaction(int sig, const struct sigaction *restrict act,
       struct sigaction *restrict oact);

DESCRIPTION

The sigaction() function allows the calling process to examine and/or specify the action to be associated with a specific signal. The argument sig specifies the signal; acceptable values are defined in .

The structure sigaction, used to describe an action to be taken, is defined in the header to include at least the following members:

Member Type	Member Name	Description
void(*) (int)	sa_handler	Pointer to a signal-catching function or one of the macros SIG_IGN or SIG_DFL.
sigset_t	sa_mask	Additional set of signals to be blocked during execution of signal-catching function.
int	sa_flags	Special flags to affect behavior of signal.
void(*) (int,
siginfo_t *, void *)	sa_sigaction	Pointer to a signal-catching function.

The storage occupied by sa_handler and sa_sigaction may overlap, and a conforming application shall not use both simultaneously.

If the argument act is not a null pointer, it points to a structure specifying the action to be associated with the specified signal. If the argument oact is not a null pointer, the action previously associated with the signal is stored in the location pointed to by the argument oact. If the argument act is a null pointer, signal handling is unchanged; thus, the call can be used to enquire about the current handling of a given signal. The SIGKILL and SIGSTOP signals shall not be added to the signal mask using this mechanism; this restriction shall be enforced by the system without causing an error to be indicated.

If the SA_SIGINFO flag (see below) is cleared in the sa_flags field of the sigaction structure, the sa_handler field identifies the action to be associated with the specified signal. ^[]  If the SA_SIGINFO flag is set in the sa_flags field, and the implementation supports the Realtime Signals Extension option or the XSI Extension option, the sa_sigaction field specifies a signal-catching function.

The sa_flags field can be used to modify the behavior of the specified signal.

The following flags, defined in the header, can be set in sa_flags:

SA_NOCLDSTOP

Do not generate SIGCHLD when children stop ^[]  or stopped children continue.

If sig is SIGCHLD and the SA_NOCLDSTOP flag is not set in sa_flags, and the implementation supports the SIGCHLD signal, then a SIGCHLD signal shall be generated for the calling process whenever any of its child processes stop ^[]  and a SIGCHLD signal may be generated for the calling process whenever any of its stopped child processes are continued.  If sig is SIGCHLD and the SA_NOCLDSTOP flag is set in sa_flags, then the implementation shall not generate a SIGCHLD signal in this way.

SA_ONSTACK

^[] If set and an alternate signal stack has been declared with , the signal shall be delivered to the calling process on that stack. Otherwise, the signal shall be delivered on the current stack.

SA_RESETHAND

^[] If set, the disposition of the signal shall be reset to SIG_DFL and the SA_SIGINFO flag shall be cleared on entry to the signal handler.

Note:

SIGILL and SIGTRAP cannot be automatically reset when delivered; the system silently enforces this restriction.

Otherwise, the disposition of the signal shall not be modified on entry to the signal handler.

In addition, if this flag is set, sigaction() behaves as if the SA_NODEFER flag were also set.

SA_RESTART

^[] This flag affects the behavior of interruptible functions; that is, those specified to fail with errno set to [EINTR]. If set, and a function specified as interruptible is interrupted by this signal, the function shall restart and shall not fail with [EINTR] unless otherwise specified. If the flag is not set, interruptible functions interrupted by this signal shall fail with errno set to [EINTR].

SA_SIGINFO

If cleared and the signal is caught, the signal-catching function shall be entered as:

void func(int signo);

where signo is the only argument to the signal-catching function. In this case, the application shall use the sa_handler member to describe the signal-catching function and the application shall not modify the sa_sigaction member.

^[] If SA_SIGINFO is set and the signal is caught, the signal-catching function shall be entered as:

void func(int signo, siginfo_t *info, void *context);

where two additional arguments are passed to the signal-catching function. The second argument shall point to an object of type siginfo_t explaining the reason why the signal was generated; the third argument can be cast to a pointer to an object of type ucontext_t to refer to the receiving thread's context that was interrupted when the signal was delivered. In this case, the application shall use the sa_sigaction member to describe the signal-catching function and the application shall not modify the sa_handler member.

The si_signo member contains the system-generated signal number.

^[] The si_errno member may contain implementation-defined additional error information; if non-zero, it contains an error number identifying the condition that caused the signal to be generated.

^[] The si_code member contains a code identifying the cause of the signal.

^[] If the value of si_code is less than or equal to 0, then the signal was generated by a process and si_pid and si_uid, respectively, indicate the process ID and the real user ID of the sender. The header description contains information about the signal-specific contents of the elements of the siginfo_t type.

SA_NOCLDWAIT

^[] If set, and sig equals SIGCHLD, child processes of the calling processes shall not be transformed into zombie processes when they terminate. If the calling process subsequently waits for its children, and the process has no unwaited-for children that were transformed into zombie processes, it shall block until all of its children terminate, and , , and shall fail and set errno to [ECHILD]. Otherwise, terminating child processes shall be transformed into zombie processes, unless SIGCHLD is set to SIG_IGN.

SA_NODEFER

^[] If set and sig is caught, sig shall not be added to the thread's signal mask on entry to the signal handler unless it is included in sa_mask. Otherwise, sig shall always be added to the thread's signal mask on entry to the signal handler.

When a signal is caught by a signal-catching function installed by sigaction(), a new signal mask is calculated and installed for the duration of the signal-catching function (or until a call to either or is made). This mask is formed by taking the union of the current signal mask and the value of the sa_mask for the signal being delivered ^[]  unless SA_NODEFER or SA_RESETHAND is set, and then including the signal being delivered. If and when the user's signal handler returns normally, the original signal mask is restored.

Once an action is installed for a specific signal, it shall remain installed until another action is explicitly requested (by another call to sigaction()), ^[]  until the SA_RESETHAND flag causes resetting of the handler,  or until one of the functions is called.

If the previous action for sig had been established by , the values of the fields returned in the structure pointed to by oact are unspecified, and in particular oact-> sa_handler is not necessarily the same value passed to . However, if a pointer to the same structure or a copy thereof is passed to a subsequent call to sigaction() via the act argument, handling of the signal shall be as if the original call to were repeated.

If sigaction() fails, no new signal handler is installed.

It is unspecified whether an attempt to set the action for a signal that cannot be caught or ignored to SIG_DFL is ignored or causes an error to be returned with errno set to [EINVAL].

If SA_SIGINFO is not set in sa_flags, then the disposition of subsequent occurrences of sig when it is already pending is implementation-defined; the signal-catching function shall be invoked with a single argument. ^[]  If the implementation supports the Realtime Signals Extension option, and if SA_SIGINFO is set in sa_flags, then subsequent occurrences of sig generated by or as a result of any signal-generating function that supports the specification of an application-defined value (when sig is already pending) shall be queued in FIFO order until delivered or accepted; the signal-catching function shall be invoked with three arguments. The application specified value is passed to the signal-catching function as the si_value member of the siginfo_t structure.

The result of the use of sigaction() and a function concurrently within a process on the same signal is unspecified.

RETURN VALUE

Upon successful completion, sigaction() shall return 0; otherwise, -1 shall be returned, errno shall be set to indicate the error, and no new signal-catching function shall be installed.

ERRORS

The sigaction() function shall fail if:

[EINVAL]

The sig argument is not a valid signal number or an attempt is made to catch a signal that cannot be caught or ignore a signal that cannot be ignored.

[ENOTSUP]

The SA_SIGINFO bit flag is set in the sa_flags field of the sigaction structure, and the implementation does not support either the Realtime Signals Extension option, or the XSI Extension option.

The sigaction() function may fail if:

[EINVAL]

An attempt was made to set the action to SIG_DFL for a signal that cannot be caught or ignored (or both).

---

The following sections are informative.

EXAMPLES

Establishing a Signal Handler

The following example demonstrates the use of sigaction() to establish a handler for the SIGINT signal.

#include 


static void handler(int signum)
{
    /* Take appropriate actions for signal delivery */
}


int main()
{
    struct sigaction sa;


    sa.sa_handler = handler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_RESTART; /* Restart functions if
                                 interrupted by handler */
    if (sigaction(SIGINT, &sa, NULL) == -1)
        /* Handle error */;


    /* Further code */
}

APPLICATION USAGE

The sigaction() function supersedes the function, and should be used in preference. In particular, sigaction() and should not be used in the same process to control the same signal. The behavior of reentrant functions, as defined in the DESCRIPTION, is as specified by this volume of IEEE Std 1003.1-2001, regardless of invocation from a signal-catching function. This is the only intended meaning of the statement that reentrant functions may be used in signal-catching functions without restrictions. Applications must still consider all effects of such functions on such things as data structures, files, and process state. In particular, application writers need to consider the restrictions on interactions when interrupting and interactions among multiple handles for a file description. The fact that any specific function is listed as reentrant does not necessarily mean that invocation of that function from a signal-catching function is recommended.

In order to prevent errors arising from interrupting non-reentrant function calls, applications should protect calls to these functions either by blocking the appropriate signals or through the use of some programmatic semaphore (see , , , and so on). Note in particular that even the "safe" functions may modify errno; the signal-catching function, if not executing as an independent thread, may want to save and restore its value. Naturally, the same principles apply to the reentrancy of application routines and asynchronous data access. Note that and are not in the list of reentrant functions. This is because the code executing after and can call any unsafe functions with the same danger as calling those unsafe functions directly from the signal handler. Applications that use and from within signal handlers require rigorous protection in order to be portable. Many of the other functions that are excluded from the list are traditionally implemented using either or functions or the standard I/O library, both of which traditionally use data structures in a non-reentrant manner. Since any combination of different functions using a common data structure can cause reentrancy problems, this volume of IEEE Std 1003.1-2001 does not define the behavior when any unsafe function is called in a signal handler that interrupts an unsafe function.

If the signal occurs other than as the result of calling , , or , the behavior is undefined if the signal handler calls any function in the standard library other than one of the functions listed in the table above or refers to any object with static storage duration other than by assigning a value to a static storage duration variable of type volatile sig_atomic_t. Furthermore, if such a call fails, the value of errno is unspecified.

Usually, the signal is executed on the stack that was in effect before the signal was delivered. An alternate stack may be specified to receive a subset of the signals being caught.

When the signal handler returns, the receiving thread resumes execution at the point it was interrupted unless the signal handler makes other arrangements. If or is used to leave the signal handler, then the signal mask must be explicitly restored.

This volume of IEEE Std 1003.1-2001 defines the third argument of a signal handling function when SA_SIGINFO is set as a void * instead of a ucontext_t *, but without requiring type checking. New applications should explicitly cast the third argument of the signal handling function to ucontext_t *.

The BSD optional four argument signal handling function is not supported by this volume of IEEE Std 1003.1-2001. The BSD declaration would be:

void handler(int sig, int code, struct sigcontext *scp,
    char *addr);

where sig is the signal number, code is additional information on certain signals, scp is a pointer to the sigcontext structure, and addr is additional address information. Much the same information is available in the objects pointed to by the second argument of the signal handler specified when SA_SIGINFO is set.

RATIONALE

Although this volume of IEEE Std 1003.1-2001 requires that signals that cannot be ignored shall not be added to the signal mask when a signal-catching function is entered, there is no explicit requirement that subsequent calls to sigaction() reflect this in the information returned in the oact argument. In other words, if SIGKILL is included in the sa_mask field of act, it is unspecified whether or not a subsequent call to sigaction() returns with SIGKILL included in the sa_mask field of oact.

The SA_NOCLDSTOP flag, when supplied in the act-> sa_flags parameter, allows overloading SIGCHLD with the System V semantics that each SIGCLD signal indicates a single terminated child. Most conforming applications that catch SIGCHLD are expected to install signal-catching functions that repeatedly call the function with the WNOHANG flag set, acting on each child for which status is returned, until returns zero. If stopped children are not of interest, the use of the SA_NOCLDSTOP flag can prevent the overhead from invoking the signal-catching routine when they stop.

Some historical implementations also define other mechanisms for stopping processes, such as the ptrace() function. These implementations usually do not generate a SIGCHLD signal when processes stop due to this mechanism; however, that is beyond the scope of this volume of IEEE Std 1003.1-2001.

This volume of IEEE Std 1003.1-2001 requires that calls to sigaction() that supply a NULL act argument succeed, even in the case of signals that cannot be caught or ignored (that is, SIGKILL or SIGSTOP). The System V and BSD sigvec() functions return [EINVAL] in these cases and, in this respect, their behavior varies from sigaction().

This volume of IEEE Std 1003.1-2001 requires that sigaction() properly save and restore a signal action set up by the ISO C standard function. However, there is no guarantee that the reverse is true, nor could there be given the greater amount of information conveyed by the sigaction structure. Because of this, applications should avoid using both functions for the same signal in the same process. Since this cannot always be avoided in case of general-purpose library routines, they should always be implemented with sigaction().

It was intended that the function should be implementable as a library routine using sigaction().

The POSIX Realtime Extension extends the sigaction() function as specified by the POSIX.1-1990 standard to allow the application to request on a per-signal basis via an additional signal action flag that the extra parameters, including the application-defined signal value, if any, be passed to the signal-catching function.

FUTURE DIRECTIONS

None.

SEE ALSO

, , , , , , , , , , , , , , , , , , , , , the Base Definitions volume of IEEE Std 1003.1-2001, ,

CHANGE HISTORY

First released in Issue 3. Included for alignment with the POSIX.1-1988 standard.

Issue 5

The DESCRIPTION is updated for alignment with the POSIX Realtime Extension and POSIX Threads Extension.

In the DESCRIPTION, the second argument to func when SA_SIGINFO is set is no longer permitted to be NULL, and the description of permitted siginfo_t contents is expanded by reference to .

Since the X/OPEN UNIX Extension functionality is now folded into the BASE, the [ENOTSUP] error is deleted.

Issue 6

The Open Group Corrigendum U028/7 is applied. In the paragraph entitled "Signal Effects on Other Functions", a reference to is added.

In the DESCRIPTION, the text "Signal Generation and Delivery", "Signal Actions", and "Signal Effects on Other Functions'' are moved to a separate section of this volume of IEEE Std 1003.1-2001.

Text describing functionality from the Realtime Signals option is marked.

The following changes are made for alignment with the ISO POSIX-1:1996 standard:

• The [ENOTSUP] error condition is added.

The DESCRIPTION is updated to avoid use of the term "must" for application requirements.

The restrict keyword is added to the sigaction() prototype for alignment with the ISO/IEC 9899:1999 standard.

References to the wait3() function are removed.

The SYNOPSIS is marked CX since the presence of this function in the header is an extension over the ISO C standard.

IEEE Std 1003.1-2001/Cor 1-2002, item XSH/TC1/D6/57 is applied, changing text in the table describing the sigaction structure.

IEEE Std 1003.1-2001/Cor 2-2004, item XSH/TC2/D6/127 is applied, removing text from the DESCRIPTION duplicated later in the same section.

IEEE Std 1003.1-2001/Cor 2-2004, item XSH/TC2/D6/128 is applied, updating the DESCRIPTION and APPLICATION USAGE sections. Changes are made to refer to the thread rather than the process.

IEEE Std 1003.1-2001/Cor 2-2004, item XSH/TC2/D6/129 is applied, adding the example to the EXAMPLES section.

End of informative text.

---

UNIX ® is a registered Trademark of The Open Group.
POSIX ® is a registered Trademark of The IEEE.
[ | | | | ]

---

===================================================================================
from:

Next: , Previous: , Up: 

---

24.3.3 Interaction of signal and sigaction

It's possible to use both the signal and sigaction functions within a single program, but you have to be careful because they can interact in slightly strange ways.

The sigaction function specifies more information than the signal function, so the return value from signal cannot express the full range of sigaction possibilities. Therefore, if you use signal to save and later reestablish an action, it may not be able to reestablish properly a handler that was established with sigaction.

To avoid having problems as a result, always use sigaction to save and restore a handler if your program uses sigaction at all. Since sigaction is more general, it can properly save and reestablish any action, regardless of whether it was established originally with signal or sigaction.

On some systems if you establish an action with signal and then examine it with sigaction, the handler address that you get may not be the same as what you specified with signal. It may not even be suitable for use as an action argument with signal. But you can rely on using it as an argument to sigaction. This problem never happens on the GNU system.

So, you're better off using one or the other of the mechanisms consistently within a single program.

Portability Note: The basic signal function is a feature of ISO C, while sigaction is part of the POSIX.1 standard. If you are concerned about portability to non-POSIX systems, then you should use the signal function instead.

===================================================================================

Next: , Previous: , Up: 

---

24.3.4 sigaction Function Example

In , we gave an example of establishing a simple handler for termination signals using signal. Here is an equivalent example using sigaction:

     #include 
     
     void
     termination_handler (int signum)
     {
       struct temp_file *p;
     
       for (p = temp_file_list; p; p = p->next)
         unlink (p->name);
     }
     
     int
     main (void)
     {
       ...
       struct sigaction new_action, old_action;
     
       /* Set up the structure to specify the new action. */
       new_action.sa_handler = termination_handler;
       sigemptyset (&new_action.sa_mask);
       new_action.sa_flags = 0;
     
       sigaction (SIGINT, NULL, &old_action);
       if (old_action.sa_handler != SIG_IGN)
         sigaction (SIGINT, &new_action, NULL);
       sigaction (SIGHUP, NULL, &old_action);
       if (old_action.sa_handler != SIG_IGN)
         sigaction (SIGHUP, &new_action, NULL);
       sigaction (SIGTERM, NULL, &old_action);
       if (old_action.sa_handler != SIG_IGN)
         sigaction (SIGTERM, &new_action, NULL);
       ...
     }

The program just loads the new_action structure with the desired parameters and passes it in the sigaction call. The usage of sigemptyset is described later; see .

As in the example using signal, we avoid handling signals previously set to be ignored. Here we can avoid altering the signal handler even momentarily, by using the feature of sigaction that lets us examine the current action without specifying a new one.

Here is another example. It retrieves information about the current action for SIGINT without changing that action.

     struct sigaction query_action;
     
     if (sigaction (SIGINT, NULL, &query_action) < 0)
       /* sigaction returns -1 in case of error. */
     else if (query_action.sa_handler == SIG_DFL)
       /* SIGINT is handled in the default, fatal manner. */
     else if (query_action.sa_handler == SIG_IGN)
       /* SIGINT is ignored. */
     else
       /* A programmer-defined signal handler is in effect. */

===================================================================================

Next: , Previous: , Up: 

---

24.3.2 Advanced Signal Handling

The sigaction function has the same basic effect as signal: to specify how a signal should be handled by the process. However, sigaction offers more control, at the expense of more complexity. In particular, sigaction allows you to specify additional flags to control when the signal is generated and how the handler is invoked.

The sigaction function is declared in signal.h.

— Data Type: struct sigaction

Structures of type struct sigaction are used in the sigaction function to specify all the information about how to handle a particular signal. This structure contains at least the following members:

sighandler_t sa_handler

This is used in the same way as the action argument to the signal function. The value can be SIG_DFL, SIG_IGN, or a function pointer. See .

sigset_t sa_mask

This specifies a set of signals to be blocked while the handler runs. Blocking is explained in . Note that the signal that was delivered is automatically blocked by default before its handler is started; this is true regardless of the value in sa_mask. If you want that signal not to be blocked within its handler, you must write code in the handler to unblock it.

int sa_flags

This specifies various flags which can affect the behavior of the signal. These are described in more detail in .

— Function: int sigaction (int signum, const struct sigaction *restrict action, struct sigaction *restrict old-action)

The action argument is used to set up a new action for the signal signum, while the old-action argument is used to return information about the action previously associated with this symbol. (In other words, old-action has the same purpose as the signal function's return value—you can check to see what the old action in effect for the signal was, and restore it later if you want.)

Either action or old-action can be a null pointer. If old-action is a null pointer, this simply suppresses the return of information about the old action. If action is a null pointer, the action associated with the signal signum is unchanged; this allows you to inquire about how a signal is being handled without changing that handling.

The return value from sigaction is zero if it succeeds, and -1 on failure. The following errno error conditions are defined for this function:

EINVAL

The signum argument is not valid, or you are trying to trap or ignore SIGKILL or SIGSTOP.

===================================================================================

===================================================================================

===================================================================================

===================================================================================

===================================================================================