Signals and Session Management

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 Signal delivered Execute normal code 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 • Check(Kernel) • ignored?return:adds the signal to p_cursig. • Interruptible sleep & !blocked? Wake up the process: nothing. • 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}

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.

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 current controlling terminal and open a new. • When the session leader terminates, it ends the login session.