09 - Signals

Class: CSCE-313

Notes:

Outline

1. What is a “signal”?
2. Signal “handling”.
3. UNIX signals API.

What is a signal?

• Signals are software interrupts. Handling signals is a way of reacting to "asynchronous" events.
  • For e.g., a user at a terminal typing the interrupt key (usually ${}^{\wedge }\mathrm{C}$ ) to stop a program.
  • The term "asynchronous" refers to the fact that signals can arrive at any time during the execution of a process, without being explicitly requested by the process.
• Every signal has a name that begins with SIG.

Examples:

• SIGABRT is the abort signal generated when a process calls the abort function.
• SIGALRM is the alarm signal generated when the timer set by the alarm function goes off.

Notes:

• If you define a handler for specific signals, you will jump directly to your defined handler the moment the signal comes in
• In the case of a signal, that something is actually written by you
• Asynchronous means that a signal can arrive at any time, even if you do not expect it.
• Examples:
  • SIGABRT generates a cool down for you -> a huge binary sort of like a debugging session
  • SIGALARM sets an alarm to be reminded of something that you need to take care on the future.

Example

cat -

• cat: reads standard input and copy that to the standard output
• But you can send it a signal:
  • you can do ^C to send an INTERRUPT signal
  • There is a setting in your terminal that bounds the key bind ^C to intr (interrupt)

> stty -a
speed 9600 baud; 52 rows; 49 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
        -echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
        -extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8
        -ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
        -dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
        eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
        min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
        stop = ^S; susp = ^Z; time = 0; werase = ^W;

• This is programmable
• We have a way of binding control sequences to actions!

If we look at the types of signals:

> kill -l
HUP INT QUIT ILL TRAP ABRT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM URG STOP TSTP CONT CHLD TTIN TTOU IO XCPU XFSZ VTALRM PROF WINCH INFO USR1 USR2

• Lists the signals that the system supports
• Some interesting ones
  • WINCH: If you are running a program and you change the window size of that program, how can the program notice this change and manage its own view (that is through the WINCH signal)
  • HUP: Hang Up Signal
  • INT: Interrupt signal
  • STOP: quite important and it cannot be handable

Q&A

What happens when you press Ctrl-C on the terminal with a running foreground process?

It is your terminal driver that is looking at the characters that is passing to the reader. There is a program at the other end that reads characters from that file, but in between there is this terminal driver that looks at all of these characters. It is the terminal drive that will send the SIGINT signal, not to a process but to the process group.

• What the shell does is that it finds a group of processes and the UNIX API is able to send the signal to this group.
• It is the kernel that looks at what processes are in that process group and delivers that SIGINT signal to each process.
• At this point, you either handle the signal or you don't
• If you do not handle the signal, the kernel will just terminate you (most times the SIGINT signal means exit)

Notes:

• Signal is entirely a software concept, it is designed to mimic a hardware interrupt, but it is solely a UNIX creation.

How to deal with runaway processes

https://www.youtube.com/watch?v=z6sDujfLNfI

• Sometimes you can't really do anything
• You either power off your machine or you get into more tricky methods

Signals are asynchronous

func (int a1, int a2) {
    int i, j = 2;
    for (i = a1; i < a2; i++) {
        j = j * 2;            // <----
        j = j / 127;          // <----
        // ...
    }
}

• A signal can come for you at any time!
• If you go into your handler you may have invariance in mind that may be violated
• This is always a trouble and we have to figure out what to do with these problems

What is the purpose of signals?

1. Allow humans to interact with programs using the terminal. For e.g.,
   • $\mathrm{Ctrl}+\mathrm{C}$ sends an interrupt signal SIGINT
   • Ctrl+Z suspends the process by sending SIGTSTP
2. Allow the kernel to enforce semantics
   • SIGSEGV is sent on memory exceptions
   • SIGILL sent on encountering illegal instructions
   • SIGPIPE when one writes to a pipe with no reader
     • This happens even mid-flight if readers exit

Notes:

• Generally CTRL+Z is programmed to SIGTSTP
  • This is possible through the wait system call
  • Children have not exited but have changed their status
• SIGSEGV: you can't really do anything significant in the handler, since the OS will redo your instruction and again give you a SIGSEGV
• SIGILL: illegal instruction, your exec system call is not checking is the instructions are valid or not, it just launches your program
  • Actually parsing a blob of binary into an instruction is not trivial
  • You can convert a trap or exception into a signal and handle it that way
  • Your program counter now is pointing to that SIGILL instruction
    • You can't actually ignore a signal
    • If you intend to ignore it won't have the desire effect
    • If you do not have an address mapped into you address space, ignoring it then won't help

Example of handler for an illegal isntruction:

void sigill_handler(int sig) {
	print("Caught SIGILL (Illegal instruction)")
}
...

UNIX System signals

• Remember SIGPIPE happens whenever one of the children does not close an end of a pipe

What can a process do about a signal-I?

A program can tell the kernel to do one of three things when a signal occurs. We call this the disposition of the signal, or the action associated with a signal.

1. Accept the default action. All signals have a default action.
   • signal(SIGINT, SIG_DFL)
   • Ignore
   • Terminate
   • Terminate and dump core
2. Ignore the signal. Works for most signals.
   • signal(SIGINT, SIG_IGN)
   • Note: cannot ignore SIGKILL and SIGSTOP. It is not advised to ignore hardware exception signals.
3. Catch the signal. (Invoke a function). Tell the kernel to invoke a given function (signal handler) whenever the signal occurs.
   • signal(SIGINT, do_something)

Notes:

• You can ignore a lot of signals by just setting the handler to be the default which a lot of times will just terminate you.

What can a process do about signal-II?

• You can override the action for some signals
  • For e.g., SIGINT, SIGUSRx, SIGTERM, SIGTSTP
• For others, you cannot (sometimes meaningfully) override
  • SIGKILL, SIGILL, SIGFPE, SIGSEGV, SIGSTOP,...
• "Overriding" is also called "signal handling", or "catching".
• SIGCHLD is the only signal so far that is ignored by default.
• Most others will kill the process except for SIGCONT, SIGSTOP, and SIGTSTP

Notes:

• The essence of being able to catch signals is to do something useful before actually exiting, otherwise why would they be useful?

Where do signals come from?

From the user: Terminal-generated signals: for e.g., ${}^{\wedge }\mathrm{C}$

• kill(2) function: Sends a signal to another process.
• kill(1) command: The command-line interface to kill(2)

From the kernel: CPU Exceptions delivered as signals

• SIGFPE divide by 0 ,
• SIGSEGV invalid memory reference,
• SIGILL when an instruction with illegal opcode is found.

From processes: Software generated signals

• SIGURG by out-of-band data on network connection
• SIGPIPE by broken pipe
• SIGALRM by timer

Notes:

• SIGURG: Sig Urgent
  • Imagine you are on an ssh connection and type Ctrl+C while on the ssh terminal, how does that affect you and the remote server?
  • The only thing between you and the other guy is the network pipe
  • Ctrl+C is not meaningful in a network pipe
  • Your network pipe is actually a bidirectional duplex stream of data
  • Even if you could get the bytes of Ctrl+C and push it into the network pipe, this Ctrl+C is living behind the blob of data.
  • At the other end what is going to happen is that your server will read in such a way that it can be processed out of band.
  • Analogy of Leading to the side when an ambulance is passing by, the network needs a fast route to reach the server so that signals can be delivered?