/* Ajith - Syntax Higlighter - End ----------------------------------------------- */
Showing posts with label Signals. Show all posts
Showing posts with label Signals. Show all posts

10.04.2009

Signals in Linux - Blocking Signals

Blocking a signal means telling the operating system to hold it and deliver it later when it is unblocked. Between the time when it is generated and when it is delivered a signal is said to be pending.

Generally, a program does not block signals indefinitely - it might as well ignore them by setting their actions to SIG_IGN. But it is useful to block signals briefly, to prevent them from interrupting sensitive operations.

Is Blocking a signal similar to Ignoring a signal ?

No, blocking a signal is different from ignoring a signal. When a process blocks a signal, the operating system does not deliver the signal until the process unblocks the signal. A process blocks a signal by modifying its signal mask with sigprocmask. But when a process ignores a signal, the signal is delivered and the process handles it by throwing it away.

How Blocking Signals is Useful ?

Temporary blocking of signals with sigprocmask gives you a way to prevent interrupts during critical parts of your code. If signals arrive in that part of the program, they are delivered later, after you unblock them.

One example where this is useful is for sharing data between a signal handler and the rest of the program. If the type of the data is not sig_atomic_t, then the signal handler could run when the rest of the program has only half finished reading or writing the data. This would lead to confusing consequences.

To make the program reliable, you can prevent the signal handler from running while the rest of the program is examining or modifying that data - by blocking the appropriate signal around the parts of the program that touch the data. Blocking signals is also necessary when you want to perform a certain action only if a signal has not arrived.

All signal blocking functions use a data structure called a signal set to specify what signals are affected. Thus, every activity involves two stages: creating the signal set, and then passing it as an argument to a library function. These facilities are declared in the header file signal.h.

The sigset_t data type is used to represent a signal set. Internally, it may be implemented as either an integer or structure type. For portability, use only the functions described below to initialize, change, and retrieve information from sigset_t objects - don't try to manipulate them directly.

#include <signal.h>

int sigemptyset(sigset_t *set);

int sigfillset(sigset_t *set);

int sigaddset(sigset_t *set, int signum);

int sigdelset(sigset_t *set, int signum);

int sigismember(const sigset_t *set, int signum);

sigemptyset function initializes the signal set given by set to empty, with all signals excluded from the set.

sigfillset function initializes set to full, including all signals.

sigaddset and sigdelset functions add and delete respectively signal signum from set.

sigismember function tests whether signum is a member of set.

Objects of type sigset_t must be initialized by a call to either sigemptyset or sigfillset before being passed to the functions sigaddset, sigdelset and sigismember.

For more information checkout: man 3 sigsetops

The collection of signals that are currently blocked is called the signal mask. Each process has its own signal mask. When you create a new process, it inherits its parent's mask. You can block or unblock signals with total flexibility by modifying the signal mask.

#include <signal.h>

int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);

In a traditional single-threaded application, sigprocmask system call can be used to fetch and/or manipulate the signal mask of the calling thread.

how determines what operation to be performed on the signal mask.
If oldset is non-null, the previous value of the signal mask is stored in oldset.
set determines list of signals to be set in blocking state.

Signals, such as SIGSTOP and SIGKILL, cannot be blocked. If an attempt is made to block these signals, the system ignores the request without reporting an error.

NOTE: Do not use sigprocmask in multi-threaded processes, because each thread has its own signal mask and there is no single process signal mask. According to POSIX, the behavior of sigprocmask in a multi-threaded process is "unspecified". Instead, use pthread_sigmask.

For more information checkout: man 2 sigprocmask

In the below example we try to block and unblock the SIGINT signal continually in a loop. If a user enters Ctrl-C while SIGINT is blocked, then the program terminates only after it is unblocked. If a user types Ctrl-C while SIGINT is unblocked, the program terminates immediately.
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char *argv[]) {
int i;
sigset_t intmask;
int repeatfactor;
double y = 0.0;

if ((sigemptyset(&intmask) == -1) || (sigaddset(&intmask, SIGINT) == -1)){
perror("Failed to initialize the signal mask");
return 1;
}

for ( ; ; ) {
printf("Entering BLOCK state\n");
if (sigprocmask(SIG_BLOCK, &intmask, NULL) == -1)
break;
fprintf(stderr, "SIGINT signal blocked\n");
sleep(2);

printf("Leaving Blocking State & Entering UNBLOCK state\n");
if (sigprocmask(SIG_UNBLOCK, &intmask, NULL) == -1)
break;
fprintf(stderr, "SIGINT signal unblocked\n");
sleep(2);
}
perror("Failed to change signal mask");
return 1;
}


Output:

$ ./a.out
Entering BLOCK state
SIGINT signal blocked
Leaving Blocking State & Entering UNBLOCK state
SIGINT signal unblocked
^C

$ ./a.out
Entering BLOCK state
SIGINT signal blocked
^CLeaving Blocking State & Entering UNBLOCK state

$

9.22.2009

Signals in Linux - Catching and Ignoring Signals - sigaction

The sigaction system call has the same basic effect as signal system call: to specify how a signal should be handled by the process.

But sigaction offers more control over the signal mechanism, 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.

Hence for reference we can say that sigaction is more like opensource Linux OS flavours more options, more control and complex for normal users than the proprietary stuff.
#include <signal.h>

int sigaction(int signum, const struct sigaction *action,struct sigaction *oldaction);

signum specifies the signal and can be any valid signal except SIGKILL and SIGSTOP.

The action argument is used to set up a new action for the signal signum, while the oldaction argument is used to return information about the action previously associated with this symbol. If action is non-null, the new action for signal signum is installed from action. If oldaction is non-null, the previous action is saved in oldaction.

For more information checkout: man 2 sigaction
struct sigaction {
void (*sa_handler)(int); /*SIG_DFL, SIG_IGN, or
a function pointer*/
void (*sa_sigaction)(int, siginfo_t *, void *);
sigset_t sa_mask;
int sa_flags;
void (*sa_restorer)(void);
};
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.
static volatile sig_atomic_t doneflag = 0;

int main (void) {
struct sigaction act;

act.sa_handler = setdoneflag;/* set up signal handler */
act.sa_flags = 0;
if ((sigemptyset(&act.sa_mask) == -1) ||
(sigaction(SIGINT, &act, NULL) == -1)) {
perror("Failed to set SIGINT handler");
return 1;
}

while (!doneflag) {
printf("press CTRL+C to kill the loop\n");
sleep(1);
}

printf("Program terminating ...\n");
return 0;
}

Output:
$ ./a.out
press CTRL+C to kill the Loop
press CTRL+C to kill the Loop
^C

In SignalHandler - setdoneflag
Program terminating ...
sig_atomic_t is an integer type that is guaranteed by the standard to not be partially written or partially read in the presence of asynchronous interrupts.

If we set act.sa_handler as SIG_DFL then the program simply terminates. If we set act.sa_handler as SIG_IGN then the program simply keeps on looping as we are ignoring the SIG_INT signal.

In the POSIX base standard, a signal handler is an ordinary function that returns void and has one integer parameter. When the operating system delivers the signal, it sets this parameter to the number of the signal that was delivered. Most signal handlers ignore this value, but it is possible to have a single signal handler for many signals. The usefulness of signal handlers is limited by the inability to pass values to them. This capability has been added to the POSIX:RTS and POSIX:XSI Extensions, which can use the alternative sa_sigaction field of the struct sigaction structure to specify a handler.

If SA_SIGINFO is specified in sa_flags, then sa_sigaction (instead of sa_handler) specifies the signal-handling function for signum. This function receives the signal number as its first argument, a pointer to a siginfo_t as its second argument and a pointer to ucontext_t (cast to void *) as its third argument. The siginfo_t argument to sa_sigaction is a struct with the following elements:
siginfo_t {
int si_signo; /* Signal number */
int si_errno; /* An errno value */
int si_code; /* Signal code */
int si_trapno; /* Trap number that caused
hardware-generated signal
(unused on most architectures)*/
pid_t si_pid; /* Sending process ID */
uid_t si_uid; /* Real user ID of sending
process */
int si_status; /* Exit value or signal */
clock_t si_utime; /* User time consumed */
clock_t si_stime; /* System time consumed */
sigval_t si_value; /* Signal value */
int si_int; /* POSIX.1b signal */
void *si_ptr; /* POSIX.1b signal */
int si_overrun; /* Timer overrun count;
POSIX.1b timers */
int si_timerid; /* Timer ID; POSIX.1b timers */
void *si_addr; /* Memory location which
caused fault */
int si_band; /* Band event */
int si_fd; /* File descriptor */
}
NOTE: si_signo, si_errno and si_code are defined for all signals (si_errno is generally unused on Linux). The rest of the struct may be a union, so that one should only read the fields that are meaningful for the given signal.
static volatile sig_atomic_t doneflag = 0;

static void setdoneflag(int sig, siginfo_t *siginfo, void *context)
{
printf ("Signo - %d\n",siginfo->si_signo);
printf ("SigCode - %d\n",siginfo->si_code);
doneflag = 1;
}

int main (int argc, char *argv[])
{
struct sigaction act;

memset (&act, '\0', sizeof(act));

act.sa_sigaction = &setdoneflag;

act.sa_flags = SA_SIGINFO;

if (sigaction(SIGINT, &act, NULL) < 0) {
perror ("sigaction");
return 1;
}

while (!doneflag) {
printf("press CTRL+C to kill the Loop\n");
sleep(1);
}

printf("Program terminating ...\n");
return 0;
}

Output:

$ ./a.out
press CTRL+C to kill the Loop
press CTRL+C to kill the Loop
^C
Signo - 2
SigCode - 128
Program terminating ...
$

9.15.2009

Signals in Linux - Catching and Ignoring Signals - signal

The simplest way to change the action for a signal is to use the signal system call. You can specify a built-in action (such as to ignore the signal), or you can establish a handler.
#include <signal.h>

typedef void (*sighandler_t)(int);

sighandler_t signal(int signum, sighandler_t handler)

signal sets the disposition of the signal signum to handler, which is either SIG_IGN, SIG_DFL, or the address of a programmer-defined function (a "signal handler").

NOTE: The signals SIGKILL and SIGSTOP cannot be caught or ignored. The effects of signal system call in a multithreaded process are unspecified.

For more information checkout: man 2 signal

NOTE: The behavior of signal system call varies across different UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction system call instead. Check man 2 signal for detailed information about various portability issues.

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>

static volatile sig_atomic_t doneflag = 0;

static void setdoneflag(int signo) {
printf("\nIn SignalHandler - setdoneflag\n");
doneflag = 1;
}

int main (void) {

signal(SIGINT, setdoneflag);

while (!doneflag) {
printf("press CTRL+C to kill the Loop\n");
sleep(1);
}

printf("Program terminating ...\n");
return 0;
}

Output:

$ ./a.out
press CTRL+C to kill the Loop
press CTRL+C to kill the Loop
press CTRL+C to kill the Loop
^C
In SignalHandler - setdoneflag
Program terminating ...
$

9.02.2009

Signals in Linux - Generating Signals

Besides signals that are generated as a result of a hardware trap or interrupt, your program can explicitly send signals to itself or to another process.

The kill system call can be used to send any signal to any process group or process.
#include <sys/types.h>
#include <signal.h>

int kill(pid_t pid, int sig);

For more information checkout: man 2 kill

There are restrictions that prevent you from using kill to send signals to any random process. These are intended to prevent antisocial behavior such as arbitrarily killing off processes belonging to another user. In typical use, kill is used to pass signals between parent, child, and sibling processes, and in these situations you normally do have permission to send signals. The only common exception is when you run a setuid program in a child process; if the program changes its real UID as well as its effective UID, you may not have permission to send a signal. The su program does this.

A process or thread can send a signal to itself with the raise function. The raise function takes just one parameter, a signal number.

In a single-threaded program it is equivalent to kill(getpid(), sig). In a multithreaded program it is equivalent to pthread_kill(pthread_self(), sig). If the signal causes a handler to be called, raise will only return after the signal handler has returned.
#include <signal.h>

int raise(int sig);

For more information checkout: man 3 raise
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>

static volatile sig_atomic_t doneflag = 10;

static void setdoneflag(int signo) {
printf("\nIn SignalHandler - setdoneflag\n");
doneflag=0;
}

int main (void) {

signal(SIGINT, setdoneflag);

while(doneflag--)
{
printf("In While loop - %d\n",doneflag);
if(doneflag==5)
raise(2);
else
sleep(1);
}

printf("Program terminating ...\n");
return 0;
}

8.25.2009

Signals in Linux - Standard Signals

Every signal has a unique signal name, an abbreviation that begins with SIG (SIGINT for interrupt signal, for example). Each signal name is a macro which stands for a positive integer - the signal number for that kind of signal. Your programs should never make assumptions about the numeric code for a particular kind of signal, but rather refer to them always by the names defined. This is because the number for a given kind of signal can vary from system to system, but the meanings of the names are standardized and fairly uniform.

The signal names are defined in signal.h (/usr/include/bits/signum.h), which must be included by any C program that uses signals.

Several signal numbers are architecture-dependent, as indicated in the "Value" column. (Where three values are given, the first one is usually valid for alpha and sparc, the middle one for ix86, ia64, ppc, s390, arm and sh, and the last one for mips. A - denotes that a signal is absent on the corresponding architecture.)



The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.

Next the signals not in the POSIX.1-1990 standard but described in SUSv2 and POSIX.1-2001.


Up to and including Linux 2.2, the default behavior for SIGSYS, SIGXCPU, SIGXFSZ, and (on architectures other than SPARC and MIPS) SIGBUS was to terminate the process (without a core dump). Linux 2.4 conforms to the POSIX.1-2001 requirements for these signals, terminating the process with a core dump.

Next various other signals.


For detailed information about the side-effects and reasons causing these signals checout libc manual.

8.23.2009

Signals in Linux - Basics

What is a Signal ?

A signal is a software interrupt delivered to notify a process or thread of a particular event. The operating system uses signals to report exceptional situations to an executing program. Some signals report errors such as references to invalid memory addresses; others report asynchronous events, such as disconnection of a phone line.

The lifetime of a signal is the interval between its generation and its delivery. A signal that has been generated but not yet delivered is said to be pending. There may be considerable time between signal generation and signal delivery. The process must be running on a processor at the time of signal delivery.
Many computer science researchers compare signals with hardware interrupts, which occur when a hardware subsystem, such as a disk I/O (input/output) interface, generates an interrupt to a processor when the I/O completes. This event in turn causes the processor to enter an interrupt handler, so subsequent processing can be done in the operating system based on the source and cause of the interrupt. When a signal is sent to a process or thread, a signal handler may be entered (depending on the current disposition of the signal), which is similar to the system entering an interrupt handler as the result of receiving an interrupt.

What causes a Signal ?

Let us see some of the events that can cause (or generate, or raise) a signal:
  • A program error such as dividing by zero or issuing an address outside the valid range.
  • A user request to interrupt or terminate the program. Most environments are set up to let a user suspend the program by typing Ctrl-z, or terminate it with Ctrl-c. Whatever key sequence is used, the operating system sends the proper signal to interrupt the process.
  • The termination of a child process.
  • Expiration of a timer or alarm.
  • A call to kill or raise system calls by the same process.
  • A call to kill from another process. Signals are a limited but useful form of interprocess communication.
  • An attempt to perform an I/O operation that cannot be done. Examples are reading from a pipe that has no writer, and reading or writing to a terminal in certain situations.
Each of these kinds of events (excepting explicit calls to kill and raise) generates its own particular kind of signal.

Signals may be generated synchronously or asynchronously. A synchronous signal pertains to a specific action in the program, and is delivered (unless blocked) during that action. Most errors generate signals synchronously, and so do explicit requests by a process to generate a signal for that same process. On some machines, certain kinds of hardware errors (usually floating-point exceptions) are not reported completely synchronously, but may arrive a few instructions later.

Asynchronous signals are generated by events outside the control of the process that receives them. These signals arrive at unpredictable times during execution. External events generate signals asynchronously, and so do explicit requests that apply to some other process. One obvious example would be the sending of a signal to a process from another process or thread via a kill system call. Asynchronous signals are also aptly referred to as interrupts.

A given type of signal is either typically synchronous or typically asynchronous. For example, signals for errors are typically synchronous because errors generate signals synchronously. But any type of signal can be generated synchronously or asynchronously with an explicit request.

How Signals Are Delivered ?

When a signal is generated, it becomes pending. Normally it remains pending for just a short period of time and then is delivered to the process that was signaled. However, if that kind of signal is currently blocked, it may remain pending indefinitely—until signals of that kind are unblocked. Once unblocked, it will be delivered immediately.

When the signal is delivered, whether right away or after a long delay, the specified action for that signal is taken. For certain signals, such as SIGKILL and SIGSTOP, the action is fixed, but for most signals, the program has a choice. Possible default dispositions are
Term   Default action is to terminate the process.
Ign Default action is to ignore the signal.
Core Default action is to terminate the process
and dump core.
Stop Default action is to stop the process.
Cont Default action is to continue the process
if it is currently stopped.
The program can also specify its own way of handling the signals (signal handlers). We sometimes say that a handler catches the signal. While the handler is running, that particular signal is normally blocked.

References:

1. Libc Manual