1 Signals and Session Management Chapter 4

2 Contents u Signal Generation and Handling u Unreliable Signals u Reliable Signals u Signals in SVR4 u Signals Implementation u Exceptions u Process Groups and Terminal Management u The SVR4 Sessions Architecture

3 4.2 Signal Generation & Handling u Signal: A way to call a procedure when some events occur. u Generation: when an event occurs. u Delivery: when the process recognizes the signal’s arrival (handling) u Pending: between generated and delivered. u System V: 15 signals u 4BSD/SVR4 : 31 signals u Signal numbers: different in different system or versions

4 Signal Handling u Default actions: each signal has a ~. u Abort: Terminate the process after generating a core dump. u Exit: Terminate the process without generating a core dump. u Ignore: Ignores the signal. u Stop: Suspend the process. u Continue: Resume the process, if suspended u Default actions may be overridden by signal handlers. (p86)

5 Signal Handling u Any action can only be done by the process. u issig() (Kernel call) u Before returning to user mode from a system call or interrupt. u Just before blocking on an interruptible event u Immediately after waking up from an interruptible event u psig(): dispatch the signal u sendsig(): invoke the user-defined handler

6 Signal Handling Execute normal code Signal delivered Resume normal code Signal handler runs

7 Signal Generation u Signal sources: u Exceptions: u Other processes: u Terminal interrupts: u Job control: u Quotas: u Notifications: u Alarms:

8 Typical Scenarios u ^C u Exceptions: u Trap: u issig(): when return to user mode. u Pending signals: processed one by one.

9 Sleep and signals u Interruptible sleep: is waiting for an event with indefinite time. u Uninterruptible sleep: is waiting for a short term event such as disk I/O u Pending the signal u Recognizing it until returning to user mode or blocking on an event u if (issig()) psig();

Unreliable Signals u Signal handlers are not persistent and do not mask recurring instances of the same signal.(SVR2) u Racing: two ^C. u Performance: SIG_DFL, SIG_IGN, u Kernel does not know the u_signal[]; u If SIG_IGN: Awake, check, and go back to sleep again(waste of time).

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

12 Reliable Signals u Primary features: u Persistent handlers: need not to be reinstalled. u Masking: A signal can be masked temporarily.(remember it) u Sleeping processes: let the signal disposition info visible to the kernel.(kept in the proc) u 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

Signals in SVR4 u sigprocmask(how, setp, osetp) u SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK u sigaltstack(stack, old_stack): u Specify a new stack to handle the signal u sigsuspend(sigmask) u Set the blocked signals mask to sigmask and puts the process to sleep u sigpending(setp) u setp contains the set of signals pending to the process

15 Signals in SVR4 u sigsendset(procset, sig) u Sends the signal sig to the set of processes procset u sigaction(signo, act, oact) u Specify a handler for signal signo. u act -> a sigaction structure u oact a function that returns the previous sigaction data u Compatibility interface: signal, sigset, sighold, sigrelse, sigignore, sigpause (sig.txt)

16 Signal flags u SA_NOCLDSTOP: Do not generate SIGCHLD when a child is suspended u SA_RESTART: Restart system call automatically if interrupted by this signal u SA_ONSTACK: Handle this signal on the alternate stack, if one has been specified by sigaltstack u SA_NOCLDWAIT: sleep until all terminate u SA_SIGINFO: additional info to the handler. u SA_NODEFER: do not block this signal u SA_RESETHAND: reset the action to default

Signals Implementation u The info needed for kernel: u u_signal[]: vector for handlers u u_sigmask[]: masks associated with handlers u u_signalstack: Pointer to the signal stack u u_sigonstack: mask of signals u u_oldsig: set of handlers exhibits the old behavior u p_cursig: The current signal being handled u p_sig: Pending signals mask u p_hold: Blocked signals mask u 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 Handling Checks 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}

Exceptions u An event when a program encounters an unusual condition(error). u Using signals to notify. u SIGSEGV u Exceptions are used by debuggers. u ptrace: a system call u Drawbacks: u Same context for signal handler and exception u Signals are for single-threaded processes. u ptrace-based debugger can control only its immediate children

Process Groups and Terminal Management u Common Concepts u Process groups: group-ID, leader u Controlling terminal: login terminal u The /dev/tty file: associated with the controlling terminal u Controlling group: the group associated with a terminal. u Job control: mechanism that can suspend or resume, or control the access to the terminal.

22 The SVR3 Model u Process groups u inherits the process group id during fork u Controlling terminal u Owned by its controlling group. u Typical scenario u init fork a child, the login shell is the leader u Terminal access: no job control u Terminal signals: ^Z, ^C, fg only u Detaching the terminal: t_pgrp = 0 u Death of group leader: exit u Implementation: proc, u area,

23 Process groups in SVR3 UNIX

24 Limitations u No way to close its controlling terminal and allocate another. u No way to preserve a login session after disconnecting from its controlling terminal. u No consistent way of handling “loss of carrier” by a controlling terminal. u The kernel does not synchronize access to the terminal by different proceses in the group. u When the group leader terminates, the kernel sends a SIGHUP signal to all processes in the group. u If a process invokes setpgrp, it will be disconnected from the controlling terminal. u No job control facilities. u A terminal emulator has no way of receiving carrier loss notification.

The SVR4 Sessions Architecture u Motivation: u Supporting both login session and job abstraction u Providing BSD style job control u Retaining backward compatibility u Allowing a login session to attach and detach several controlling terminals u Making the session leader responsible fro maintaining the session’s integrity and security. u Allowing terminal access based solely on file access permissions. u Eliminating inconsistencies of earlier implementation.

26 Sessions and Process Group u Create a session: setsid makes the caller the leader of both the session and the group. u fg group and bg group u Inherit group: u Change a session: by setpgid(pid, pgid) u Move: within a session u Leave a session: by setsid

27 SVR4 Sessions Architecture

28 Data Structure u setsid : allocates a new session structure and resets the p_sessp & p_pgidp in the proc.

29

30 Controlling Terminals u Login u Calls setsid to become a session leader u Close stdin, stdout, stderr u Calls open to open a designated terminal u Duplicates this descriptor elsewhere u Opens /dev/tty as stdin, and duplicates stdout, and stderr u Close the saved descriptor

31 Controlling Terminals u The session leader is a trusted process. u The driver sends SIGTSTP to fg process group. u A session leader may disconnect the current controlling terminal and open a new. u When the session leader terminates, it ends the login session.