1. Signals
Tanzir Ahmed CSCE 313 Fall 2018

2. Inter-Process Communication
IPC classes
Pipes and FIFO
Message Passing
Shared Memory
Semaphore Sets
Signals
References:
Baseline slides: CSCE-313 Tyagi, Bettati, Gu
Advanced Programming in the UNIX Environment, Third Edition, W. Richard Stevens and Stephen A. Rago, Addison-Wesley Professional Computing Series, Chapters 10, 15
Understanding Unix/Linux Programming, Bruce Molay, Chapter 6
Advanced Linux Programming Ch 5
Some material also directly taken or adapted with changes from Illinois course in System Programming (Prof. Angrave), UCSD (Prof. Snoeren), and USNA (Prof. Brown)

3. Inter-Process Communication Landscape
Multiple approaches and mechanisms for processes to communicate to one another. Named Pipe (FIFO), Semaphores, Message Passing, Shared Memory, Signals are some of the principal mechanisms for IPC
Rendering from Prof. Farrell (Kent State University)

4. Background: User-Mode Exceptional Flow
So far exceptional control flow features have been usable only by the operating system
Exceptions:
Synchronous: faults, traps, aborts
Asynchronous: interrupts
All exception handlers run in protected (Kernel) mode
Would like similar capabilities for user mode code
Inter-Process communication to facilitate ‘exceptional control flow’ is subject of today’s discussion
We will discuss them through “Signals” mechanism
……but also in a broader context beyond just IPC

5. Example: What does CTRL-C do?
Taken from: Chapter 6 of “Understanding Unix/Linux Programming” by Bruce Molay

6. What is a Signal? A Signal is a one-word message
A Green Light is a signal, A Referee’s whistle is a signal
These items and events do not contain messages, they are messages!
Each Signal has a numerical code
So when we press CTRL-C key we ask the Kernel to send the interrupt signal to the currently running process

7. List of Signals
Terminate and also dump core (for further investigation)
Will be ignored by default, unless you override
Process scheduler??
Source of table:
Multiple values mean that they are different based on architecture

8. Signals – Some Points
The “Action” in the previous page in many cases indicate the “Default Action”
You are allowed to “override” the action for some signals (e.g., SIGINT, SIGUSRx, SIGTERM, SIGSTP), while for others (SIGKILL, SIGILL, SIGFPE, SIGSEGV, SIGSTOP) you cannot override
This 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 SIGCONT and SIGSTP
Does that mean you can kill any process by sending any signal??
NO. You can only signal processes that you created
SIGSTP (suspends a process) and SIGCONT (conitues/unsuspends a process) are very useful for “job control”
How to control a process group tied by a shell session?
All processes that you run make a group of processes that need special controlling
You may suspend a process, run it in the background, move to foreground
What happens to standard input/output of a background process?

9. Where do Signals come from?
Today we’ll look at Signals in a broader context
IPC is one of the contexts (one process sending to another)
Others are facilitated by Users and Kernel
[Users] Signals generated by external Input devices
[Kernel] Exceptions
This is a fairly accurate description of relationship between exceptions and signals as stated in WIKIPEDIA or any other commonly available references:
A process's execution may result in the generation of a hardware exception, for instance, if the process attempts to divide by zero or incurs a TLB miss.
In Unix-like operating systems, this event automatically changes the processor context to start executing a Kernel exception handler. In case of some exceptions, such as a page fault, the Kernel has sufficient information to fully handle the event itself and resume the process's execution.
Other exceptions, however, the Kernel cannot process intelligently and it must instead defer the exception handling operation to the faulting process. This deferral is achieved via the signal mechanism, wherein the Kernel sends to the process a signal corresponding to the current exception. For example, if a process attempted integer divide by zero on an x86 CPU, a divide error exception would be generated and cause the Kernel to send the SIGFPE signal to the process.
Similarly, if the process attempted to access a memory address outside of its virtual address space, the Kernel would notify the process of this violation via a SIGSEGVsignal. The exact mapping between signal names and exceptions is obviously dependent upon the CPU, since exception types differ between architectures.
Taken from: Chapter 6 of “Understanding Unix/Linux Programming” by Bruce Molay

10. Where do Signals come from?
(USER) Terminal-generated signals: triggered when user presses certain key on terminal. (e.g. ^C) kill(2) function: Sends any signal to another process. kill(1) command: The command-line interface to kill(2) raise(3): Sends a signal to itself A user can send signals to only his owned processes (Kernel) Exception-generated signals: CPU execution detects condition and notifies Kernel. (e.g. SIGFPE divide by 0, SIGSEGV invalid memory reference, SIGILL when an instruction will illegal opcode is found) (PROCESSES) Software-condition generated signals: Triggered by software event (e.g. SIGURG by out-of-band data on network connection, SIGPIPE by broken pipe, SIGALRM by timer)

11. Generating Signals: kill(2) and raise(3)
#include <signal.h>
int kill(pid_t pid, int sig);
/* send signal ‘sig’ to process ‘pid’ */
/* example: send signal SIGUSR1 to process 1234 */
if (kill(1234, SIGUSR1) == -1)
perror(“Failed to send SIGUSR1 signal”);
/* example: kill parent process */
if (kill(getppid(), SIGTERM) == -1)
perror(“Failed to kill parent”);
#include <signal.h>
int raise(int sig);
/* Sends signal ‘sig’ to itself.
Part of ANSI C library! */
“raise” is defined by ANSI C, not POSIX.1. Since ANSI C does not deal with multiple processes it could not define a function such as “kill” that requires a process ID argument.
Raise sends a signal to the executing process
Kill sends a signal to the specified process

12. Signals and the Kernel
Many of the signals are generated by the Kernel in response to events and exceptions received
SIGFPE – FP exception
SIGILL – Illegal instruction
SIGSEGV – Segment Violation
Many others are routed through the Kernel, if not originating from the Kernel itself
E.g. SIGHUP (terminal hang), SIGINT (CTRL-C keyboard), SIGTSTP (CTRL-Z), SIGKILL (KILL)
As with system calls, the Kernel receives the signals from hardware and other processes on behalf of a process
Then Kernel forwards the signal to the appropriate process

13. What can a Process do about a Signal?
Tell the Kernel what to do with a signal:
Accept Default action. All signals have a default action signal (SIGINT, SIG_DFL)
Ignore the signal. Works for most signals
signal (SIGINT, SIG_IGN)
cannot ignore SIGKILL and SIGSTOP; also unwise to ignore hardware exception signals
Catch the signal (call a function). Tell the Kernel to invoke a given function (signal handler) whenever signal occurs. signal (SIGINT, foo)

14. Signal – Subtle Differences
SIGTERM
The SIGTERM signal is a generic signal used to cause program termination. Unlike SIGKILL, this signal CAN be blocked, handled, or ignored. It is the normal way to politely ask a program to terminate.
SIGINT
The SIGINT (“program interrupt”) signal is sent when the user types Ctrl+C. CAN be handled and even ignored
SIGKILL
The SIGKILL signal is used to cause immediate program termination. It CANNOT be blocked, handled or ignored. It is a last resort, after first trying SIGINT or SIGTERM
SIGHUP
The SIGHUP (“hang-up”) signal is used to report that the user’s terminal is disconnected, perhaps because a network or telephone connection (????) was broken.

15. Simple Signal Handling: Example
Taken from: Chapter 6 of “Understanding Unix/Linux Programming” by Bruce Molay

16. Example – One Handler for Multiple Signals
static void sig_usr(int); /* one handler for two signals */
int main (void) {
if (signal(SIGUSR1, sig_usr) == SIG_ERR)
perror(“cannot catch signal SIGUSR1”);
if (signal(SIGUSR2, sig_usr) == SIG_ERR)
perror(“cannot catch signal SIGUSR2”);
for(;;) pause(); }
static void sig_usr(int signo) { /*argument is signal number*/
if (signo == SIGUSR1) printf(“received SIGUSR1\n”);
else if (signo == SIGUSR2) printf(“received SIGUSR2\n”);
else error_dump(“received signal %d\n”, signo);
return;

17. Signals: Terminology
A signal is generated for a process when event that causes the signal occurs. (Hardware exception, software condition, etc.)
A signal is delivered when action for a signal is taken.
During the time between generation and delivery, signal is pending.
That is also the lifecycle of a signal
A process has the option of blocking the delivery of a signal.
Signal remains blocked until process either (a) unblocks the signal, or (b) changes the action to ignore the signal.

18. Signals: Terminology
A blocked signal is generated like other signals, but is not delivered to the target process
What happens when blocked signal is generated more than once?
If system delivers the signal more than once, the signal is queued
signal mask is the mechanism to define set of signals that are blocked from delivery
Checkout the function: sigprocmask(..)
There are 2 critical signal sets that the Kernel maintains
Pending Signals Set
Blocked Signals Set

19. Pending Signals Set
A bit vector known as pending bit vector of signals that are currently pending for the process
These signals have been sent to the process, but haven’t yet been handled by the process
A process does not manipulate the pending set directly
Residency in pending set means that this signal is currently blocked (discussed next) by the process
Each kind of signal has one bit assigned to it - If a particular signal type is already pending and is sent again, the second signal is dropped

20. Blocked Signals
The Kernel also keeps a blocked bit-vector for each process
The process itself manipulates this vector through system calls
Each type of signal has a bit assigned to it
If a particular type of signal is blocked, it will not be delivered to the process until unblocked
In the meantime, the pending set will keep collecting this signal
When the Kernel calls a signal handler on a process, that type of signal is automatically blocked
Generally signal handlers don’t need to worry about being interrupted by the same kind of signal again
Does this sound like “Interrupts being blocked while handling an interrupt”???

21. Blocked Signals (2) Example: A process with a SIGINT handler
First, SIGINT received causes the SIGINT handler to be called
Also causes SIGINT to be blocked for the process - If another SIGINT occurs during Handler execution, it is recorded in the pending bit vector, but not delivered
When a signal handler returns, the blocked signal type is automatically unblocked
When handler returns, signals of that type can start to be delivered again
Several functions for manipulating these signal bit vectors
sigpending (returns current pending signals for the process)
sigprocmask (manipulate the set of blocked signals for the process)

22. Signals Concept Refresh
Where do signals come from?
User, Kernel, Process
What can a process tell the Kernel to do about a Signal?
Accept Default, Ignore, Catch
A Signal is “Generated” when ……
event that causes the signal occurs
A Signal is “Delivered” when ……
action for signal is taken

23. Signals Concept Refresh (2)
A Signal is “Blocked” when …..
it is not allowed to be delivered
signal mask can be used to control ……
set of signals that are blocked from delivery
When the Kernel calls a signal handler on a process, that type of signal is ……
automatically blocked
When a signal handler returns, the blocked signal type is …….
automatically unblocked

24. SUMMARY: Signals
Signals share many common traits with hardware exception handling
A user-mode version of hardware exceptions
When a signal handler is invoked that type of signal is blocked until the handler returns
Very similar to H/W interrupts
Signals allow us to leverage exceptional control flow in user programs
Enables powerful techniques in server programming
Are widely used in server programs
Web servers, servers, DNS servers, Databases, etc.