So far, we know how to create processes. How do we communicate with them? Primary mechanism: signals

Transcription

1 Signals Page 1 Signals and handlers Thursday, September 14, :58 AM So far, we know how to create processes. How do we communicate with them? Primary mechanism: signals

2 Vocabulary Thursday, September 14, :00 PM Signal: a message sent to a process with a specific meaning. Signal codes are integers. There is a reserved meaning for many of these signals. Other meanings can be user defined. Handler: a piece of code that deals with the receipt of a signal Invoked automatically upon receipt of a signal. Optional. Default behaviors are predefined for many signals. Some signals cannot be handled. Signals Page 2

3 Some important signals Thursday, September 14, :20 PM Signal Number Description SIGHUP 1 Hangup (POSIX) SIGINT 2 Terminal interrupt (ANSI) SIGQUIT 3 Terminal quit (POSIX) SIGILL 4 Illegal instruction (ANSI) SIGTRAP 5 Trace trap (POSIX) SIGIOT 6 IOT Trap (4.2 BSD) SIGBUS 7 BUS error (4.2 BSD) SIGFPE 8 Floating point exception (ANSI) SIGKILL 9 Kill(can't be caught or ignored) (POSIX) SIGUSR1 10 User defined signal 1 (POSIX) SIGSEGV 11 Invalid memory segment access (ANSI) SIGUSR2 12 User defined signal 2 (POSIX) SIGPIPE 13 Write on a pipe with no reader, Broken pipe (POSIX) SIGALRM 14 Alarm clock (POSIX) SIGTERM 15 Termination (ANSI) SIGSTKFLT 16 Stack fault SIGCHLD 17 Child process has stopped or exited, changed (POSIX) SIGCONT 18 Continue executing, if stopped (POSIX) SIGSTOP 19 Stop executing(can't be caught or ignored) (POSIX) SIGTSTP 20 Terminal stop signal (POSIX) SIGTTIN 21 Background process trying to read, from TTY (POSIX) SIGTTOU 22 Background process trying to write, to TTY (POSIX) SIGURG 23 Urgent condition on socket (4.2 BSD) SIGXCPU 24 CPU limit exceeded (4.2 BSD) SIGXFSZ 25 File size limit exceeded (4.2 BSD) SIGVTALRM 26 Virtual alarm clock (4.2 BSD) SIGPROF 27 Profiling alarm clock (4.2 BSD) SIGWINCH 28 Window size change (4.3 BSD, Sun) SIGIO 29 I/O now possible (4.2 BSD) SIGPWR 30 Power failure restart (System V) From < Signals Page 3

4 Sending a signal Thursday, September 14, :19 PM keyboard command C program Meaning control-c kill {pid} kill(pid, SIGINT) Stop the program permanently control-z kill -TSTP {pid} kill(pid, SIGTSTP) Suspend the program temporarily control-\ kill -QUIT {pid} kill(pid, SIGQUIT) Stop the program immediately and produce a core dump. (where {pid} is the process id to which to send the signal) What about other signals? They can't be sent from the keyboard but the other forms all work for them. Signals Page 4

5 Signals Page 5 A curious historical issue Thursday, September 14, :42 PM The "send" command for a signal is "kill". Sending many signals doesn't kill a process. In other words, "kill" doesn't necessarily "kill" anything.

6 Really killing something Thursday, September 14, :26 PM ps -ef grep {your-login} # find the PID of a stuck process kill -KILL {pid} # kill the stuck process There are four severities for actually killing a process TER be really nice about it, close all files M INT let operations complete and then die QUIT stop with extreme prejudice and make a core dump KILL don't pass go or collect $200, just die; don't even debug! Most people use INT (control-c) most of the time. TERM is used for killing database daemons without losing data. KILL is used for stuck processes that won't otherwise die. KILL cannot be caught or ignored. Signals Page 6

7 Signals Page 7 Some simple kill examples Saturday, September 16, :00 AM lint.c Kill one's own child. usr1.c Send a request to report status via the USR1 signal (userdefined). To make thsi work, type killall -USR1 a.out where a.out is the name of the program, in a different shell. The latter one uses a handler to receive the signal.

8 Subtle kill options: process groups Monday, September 18, :13 PM kill(-pid, signal): send signal to every process in pid's process group. kill(0, signal): send signal to every process in my process group. A process group is a set of processes engaged in one task. By default, the children of a process are in the same group. One can put a process into a new group by calling setpgid(). One's group id is the pid of the process that is group leader. One can query the group id via getpgid() Signals Page 8

9 Signals Page 9 A true story Monday, September 18, :27 PM Assignment: stop fork bombs of the form while(1) fork() Proper solution: kill (-pid, SIGKILL) where pid is the pid of a participating process. This particular bomb leaves all processes in the same process group. A very poor solution: do a ps of all children for every child kill(pid, SIGKILL) Why is this so bad? In the first solution, all of the children of the fork bomb are killed at once, in one step. This includes parents and children of pid in the same process group. The reason is that the fork bomb, by construction, always produces processes in the same process group. In the second solution, everything works well

10 Signals Page 10 until you kill a group leader. Then all of the children of that group leader become leaders of their groups. These individual groups fork independently. Thus there is no longer a single command that can stop this, and even repeating kill(- pid, SIGKILL) a lot of times, it takes a while to kill all of the groups that result. It is usually easier to power-cycle the machine.

11 Signals Page 11 The concept of a handler Thursday, September 14, :49 PM A handler is a fragment of code that is called like a subroutine when a signal is received. Handlers have no arguments other than the signal identity (how could they?) Returning from the handler resumes where the code was interrupted. Resuming is not always possible. One cannot resume from a SEGV or BUS signal (segmentation fault or bus error). Upon receiving a signal, a handler can exit from the program do nothing at all and return to the program. take remedial action and then return to the program. For example, it can print an informative message or change a variable. Constructing a handler: signal(name, handler) "registers" a signal handler. The definition of handler is void handler(int signal) { }

12 Signals Page 12 Some examples of handlers Saturday, September 16, :06 AM chld.c Reap status code from dead children without process intervention. int.c Specifically respond to a SIGINT by taunting the user. segv.c Trap a segmentation fault and print a friendlier message for COMP11 students. bus.c Trap a bus error and send a friendlier message. alrm.c Use the alarm function to send a signal after a specified time. usr1.c Use the SIGUSR1 signal to get a process to report its

13 status. Run this example and then issue killall USR1 a.out In another shell on the same machine to see it report its status. Signals Page 13

14 Some definitions of what handlers should do Saturday, September 16, :36 PM There are a number of conventions in linux that loosely determine what one should do when one receives a signal: SIGHUP Hangup Reinitialize the application and re-read any data files. SIGTERM Graceful exit Close all files and exit gracefully. These are up to the application to perform. There are several signals that stop the application no matter how you handle them: SIGSEGV Segmentation violation SIGBUS SIGILL Bus error Illegal instruction There are also several signals that are operation-specific: SIGCHLD Child changed status SIGIO SIGPIPE I/O available Broken pipe SIGALRM Alarm clock Signals Page 14

15 Signals Page 15 Caveats about handlers Saturday, September 16, :11 AM The KILL signal cannot be handled. It is meant for situations in which the process is so messed up that it is preventing one from killing it otherwise. Signal handling can "stack", in the sense that it is possible for a handler to be called during a handler. Signal handlers use a different stack than the execution stack, to avoid stack conflicts.

16 Signals Page 16 Blocking signals Saturday, September 16, :14 AM It is possible to "block" a signal, so that Its handler is not called. It waits for itself to be unblocked. When unblocked, it is handled. block.c The simple way to block a signal for a given time. If you run this and type control-c, it is not ignored; it is instead deferred until the end of the loop.

17 Signals Page 17 System calls, deprecation, and POSIX Saturday, September 16, :26 AM If you compile the program in the last slide, you will be warned that sigsetmask is deprecated. In fact, all examples I presented so far are considered obsolete. They are easy to understand, but do not represent best programming practices. The Portable Operating System Interface (POSIX) standard defines a standard format for system calls that is supported in most operating systems, regardless of their local conventions. In general, POSIX is a bit more powerful -- but a bit more cumbersome -- than local system call conventions that evolved for linux/unix in isolation. If you want your program to be portable to other operating systems, use POSIX. Signal handling is drastically different in POSIX than in linux proper; POSIX is desirable but more difficult to use.

18 Signals Page 18 Non-POSIX handlers Thursday, September 14, :38 PM void handler(sig) { sigsetmask(sigmask(sigusr1)); printf("i received signal %d\n", sig); sigsetmask(0); }... signal(sigint, handler); Causes SIGUSR1 to print a message.

19 Signals Page 19 POSIX handlers Thursday, September 14, :43 PM The same exact handler in POSIX: void action(int sig, siginfo_t info, void *buf) { printf("i received signal %d\n", sig); } struct sigaction sa, old_sa; sigset_t mask; sigemptyset(&mask); // only block issued signal sa.sa_sigaction = action; sa.sa_mask = mask; sa.sa_flags = SA_SIGINFO; sigaction(sigusr1, &sa, &old_sa); siginfo_t: information about the signal. sa_mask: a bitmask of signals to block (the incoming signal is blocked automatically) sa_flags: a bitmask of flags that modify the action. Note that the signal that invoked the action is automatically blocked, unless sa_flags includes SA_NODEFER; See

20 action.c For an example for SIGCHLD. Signals Page 20

21 Signals Page 21 Why you should use POSIX signal handling Thursday, September 14, :50 PM You should use the POSIX form even if portability is not a concern. Why? This is super-subtle. POSIX does some things in the kernel that the local signal handler does not. The most important of these is that it prevents a signal from being invoked twice by combining blocking with signal invocation. The native linux version does not. The reason is how the two solutions mask signals that you don't want to happen during the signal handler. It is not possible to prevent signals during a signal handler using the signal() function and sigblock(). Here's why: void handler(int sig) { // when execution is here, signals can stack. sigsetmask(sigmask(sigint)); // now signals cannot stack. }

22 Signals Page 22 There is a small amount of time after the handler is invoked that another signal can be sent and recursively invoke the handler while it is running. For some signals, this is not harmful, e.g., SIGINT, SIGSEGV, etc. For other signals, it is quite annoying, e.g., SIGUSR1, SIGHUP, etc. These signals don't stop the process, but instead, instruct it to do something. Without blocking, it gets done twice.

23 Signals Page 23 POSIX mask handling Saturday, September 16, :29 PM There are macros that shield you from what is really going on, which include integer bit operations. sigset_t mask, old_mask; sigemptyset(&mask); sigaddset(&mask, SIGINT); sigprocmask(sig_block, &mask, &old_mask); See procmask.c In the first loop, control-c is deferred. When the mask is unblocked, the control-c's that might have been sent earlier are interpreted.

24 Signals Page 24 Masks, ints, and set operations Thursday, September 14, :53 PM You can see in the sample code that there is a consistent pattern of using integers as bitfields to represent sets of options. For example, options are integers with single bits set to 1, and one uses "bitwise OR" ( ) to combine them. For example, when calling open to open a file, one has options O_RDWR and O_CREAT that can be combined via fd = open("foo", O_RDWR O_CREAT) to specify that one should be able to read and write the file, and one should create it if it doesn't exist.

25 Signals Page 25 Understanding bitmasks Saturday, September 16, :47 PM A B is the bitwise OR of two integers A and B. A & B is the bitwise AND of two integers A and B. ~A is the complement of the integer A. (1<<A) is the integer with a 1 in position A, zeros elsewhere. So, to set bit A of X: X = X (1<<A) To unset bit A of X: X = X & (~(1<<A)) To test bit A of X: (X & (1<<A))!= 0 An integer with the first A bits equal to 1: (1<<A)-1 This is how the bit operations in sigemptymask, sigaddmask work. They're just hidden from you. More generally, one can select k bits out of an integer X, at offset m, with the expression (X>>m) & ((1<<k) - 1)