1

Signals and Session Management

Chapter 4

2

Contents Signal Generation and Handling Unreliable Signals Reliable Signals Signals in SVR4 Signals Implementation Exceptions Process Groups and Terminal

Management The SVR4 Sessions Architecture

3

4.2 Signal Generation & Handling

Signal: A way to call a procedure when some events occur.

Generation: when an event occurs. Delivery: when the process recognizes the

signal’s arrival (handling) Pending: between generated and delivered. System V: 15 signals 4BSD/SVR4 : 31 signals Signal numbers: different in different system

or versions

4

Signal Handling Default actions: each signal has a ~.

Abort: Terminate the process after generating a core dump.

Exit: Terminate the process without generating a core dump.

Ignore: Ignores the signal. Stop: Suspend the process. Continue: Resume the process, if suspended

Default actions may be overridden by signal handlers. (p86)

5

Signal Handling Any action can only be done by the process. issig() (Kernel call)

Before returning to user mode from a system call or interrupt.

Just before blocking on an interruptible event Immediately after waking up from an interruptible

event

psig(): dispatch the signal sendsig(): invoke the user-defined handler

6

Signal Handling

Execute normal code

Signal delivered

Resume normal code

Signal handler runs

7

Signal Generation Signal sources:

Exceptions: Other processes: Terminal interrupts: Job control: Quotas: Notifications: Alarms:

8

Typical Scenarios ^C Exceptions:

Trap: issig(): when return to user mode.

Pending signals: processed one by one.

9

Sleep and signals Interruptible sleep: is waiting for an

event with indefinite time. Uninterruptible sleep: is waiting for a

short term event such as disk I/O Pending the signal Recognizing it until returning to user mode

or blocking on an event if (issig()) psig();

10

4.3 Unreliable Signals Signal handlers are not persistent and

do not mask recurring instances of the same signal.(SVR2)

Racing: two ^C. Performance: SIG_DFL, SIG_IGN,

Kernel does not know the u_signal[]; If SIG_IGN: Awake, check, and go back to

sleep again(waste of time).

11

Reinstalling a signal handler void sigint_handler(sig) int sig; { signal(SIGINT, sigint_handler); … } main() { signal(SIGINT, sigint_handler); … }//sig.c

12

Reliable Signals Primary features:

Persistent handlers: need not to be reinstalled.

Masking: A signal can be masked temporarily.(remember it)

Sleeping processes: let the signal disposition info visible to the kernel.(kept in the proc)

Unblock and wait: sigpause()-automatically unmasks a signal and blocks the process.

13

The SVR3 implementation int sig_received = 0; void handler (int sig) { sig_received++; } main() { sigset (SIGQUIT, handler); sighold(SIGQUIT); while (sig_received ==0) sigpause(SIGINT); }//sig1.c

14

4.5 Signals in SVR4 sigprocmask(how, setp, osetp)

SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK sigaltstack(stack, old_stack):

Specify a new stack to handle the signal sigsuspend(sigmask)

Set the blocked signals mask to sigmask and puts the process to sleep

sigpending(setp) setp contains the set of signals pending to the

process

15

Signals in SVR4 sigsendset(procset, sig)

Sends the signal sig to the set of processes procset

sigaction(signo, act, oact) Specify a handler for signal signo. act -> a sigaction structure oact a function that returns the previous sigaction

data

Compatibility interface: signal, sigset, sighold, sigrelse, sigignore, sigpause (sig.txt)

16

Signal flags SA_NOCLDSTOP: Do not generate SIGCHLD

when a child is suspended SA_RESTART: Restart system call

automatically if interrupted by this signal SA_ONSTACK: Handle this signal on the

alternate stack, if one has been specified by sigaltstack

SA_NOCLDWAIT: sleep until all terminate SA_SIGINFO: additional info to the handler. SA_NODEFER: do not block this signal SA_RESETHAND: reset the action to default

17

4.6 Signals Implementation

The info needed for kernel: u_signal[]: vector for handlers u_sigmask[]: masks associated with handlers u_signalstack: Pointer to the signal stack u_sigonstack: mask of signals u_oldsig: set of handlers exhibits the old behavior p_cursig: The current signal being handled p_sig: Pending signals mask p_hold: Blocked signals mask p_ignore: Ignored signals mask

18

Signal Generation

1. Check(Kernel)

2. ignored?return:adds the signal to p_cursig.

3. Interruptible sleep & !blocked? Wake up the process: nothing.

4. SIGSTOP or SIGCONT suspend or resume

19

Delivery and HandlingChecks by issig()

If (1 bit(p_cursig) set) {if ( ! p_hold )

{store the signal number in p_sig, return TRUE}else

{psig()} psig(){

If (no handler) default;else invoke a handler {if (! SA_NODEFER) change p_hold;If (SA_RESETHAND) u_signal[] is reset to SIG_DFL;} sendsig(); //machine-dependent}

20

4.7 Exceptions An event when a program encounters an

unusual condition(error). Using signals to notify.

SIGSEGV Exceptions are used by debuggers.

ptrace: a system call Drawbacks:

Same context for signal handler and exception Signals are for single-threaded processes. ptrace-based debugger can control only its

immediate children

21

4.9 Process Groups and Terminal Management

Common Concepts Process groups: group-ID, leader Controlling terminal: login terminal The /dev/tty file: associated with the

controlling terminal Controlling group: the group associated

with a terminal. Job control: mechanism that can suspend

or resume, or control the access to the terminal.

22

The SVR3 Model Process groups

inherits the process group id during fork Controlling terminal

Owned by its controlling group. Typical scenario

init fork a child, the login shell is the leader Terminal access: no job control Terminal signals: ^Z, ^C, fg only Detaching the terminal: t_pgrp = 0 Death of group leader: exit Implementation: proc, u area,

23

Process groups in SVR3 UNIX

24

Limitations No way to close its controlling terminal and allocate

another. No way to preserve a login session after disconnecting

from its controlling terminal. No consistent way of handling “loss of carrier” by a

controlling terminal. The kernel does not synchronize access to the terminal

by different proceses in the group. When the group leader terminates, the kernel sends a

SIGHUP signal to all processes in the group. If a process invokes setpgrp, it will be disconnected from

the controlling terminal. No job control facilities. A terminal emulator has no way of receiving carrier loss

notification.

25

4.10 The SVR4 Sessions Architecture

Motivation: Supporting both login session and job abstraction Providing BSD style job control Retaining backward compatibility Allowing a login session to attach and detach

several controlling terminals Making the session leader responsible fro

maintaining the session’s integrity and security. Allowing terminal access based solely on file

access permissions. Eliminating inconsistencies of earlier

implementation.

26

Sessions and Process Group Create a session: setsid makes the

caller the leader of both the session and the group. fg group and bg group Inherit group:

Change a session: by setpgid(pid, pgid) Move: within a session Leave a session: by setsid

27

SVR4 Sessions Architecture

28

Data Structure setsid : allocates a new session

structure and resets the p_sessp & p_pgidp in the proc.

29

30

Controlling Terminals Login

Calls setsid to become a session leader Close stdin, stdout, stderr Calls open to open a designated terminal Duplicates this descriptor elsewhere Opens /dev/tty as stdin, and duplicates

stdout, and stderr Close the saved descriptor

31

Controlling Terminals The session leader is a trusted process. The driver sends SIGTSTP to fg process

group. A session leader may disconnect the curr

ent controlling terminal and open a new. When the session leader terminates, it e

nds the login session.