310 likes | 609 Views
Signals and Session Management. Chapter 4. Contents. Signal Generation and Handling Unreliable Signals Reliable Signals Signals in SVR4 Signals Implementation Exceptions Process Groups and Terminal Management The SVR4 Sessions Architecture. 4.2 Signal Generation & Handling.
E N D
Signals and Session Management Chapter 4
Contents • Signal Generation and Handling • Unreliable Signals • Reliable Signals • Signals in SVR4 • Signals Implementation • Exceptions • Process Groups and Terminal Management • The SVR4 Sessions Architecture
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
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)
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
Signal Handling Signal delivered Execute normal code Resume normal code Signal handler runs
Signal Generation • Signal sources: • Exceptions: • Other processes: • Terminal interrupts: • Job control: • Quotas: • Notifications: • Alarms:
Typical Scenarios • ^C • Exceptions: • Trap: • issig(): when return to user mode. • Pending signals: processed one by one.
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();
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).
Reinstalling a signal handler • void sigint_handler(sig) • int sig; • { signal(SIGINT, sigint_handler); • … • } • main() • { signal(SIGINT, sigint_handler); • … • }//sig.c
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.
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
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
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)
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
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
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
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}
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
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.
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,
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.
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.
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
Data Structure • setsid : allocates a new session structure and resets the p_sessp & p_pgidp in the proc.
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
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.