Signals and Semaphores


A signal is a notification sent to a process that an event has occurred. These events may include hardware or software faults, terminal activity, timer expiration, changes in the status of a child process, changes in a window size, and so forth. A list of the 30 most common signals is given in Table 11–1 (there are actually about 45 signals).

Each process may specify an action to be taken in response to any signal other than the kill signal. The action can be any of these:

  • Take the default action for the signal:

    • Exit means receiving process is terminated.

    • Core means receiving process is terminated and leaves a “core image” in the current directory Using the core dump for debugging is discussed in Chapter 24.

    • Stop means receiving process stops.

  • Ignore the signal.

  • On receiving a signal, execute a signal-handling function defined for this process.

Many of the signals are used to notify processes of special events that may not be of interest to a user. Although most of them can have user impact (e.g., power failures and hardware errors), there is not much a user can do in response. A notable exception for users and for shell programmers is the HUP or hangup signal. You can control what will happen after you hang up or log off.

The UNIX systems use signals to notify a specific process about its current state. However, many processes run simultaneously on a typical machine. At times, more than one process may want to use a particular system resource in order to execute. UNIX handles this situation by using semaphores. A semaphore is a value that the operating system makes available to processes to check whether or not the resource is currently being used. If a resource is free (not in use), a process can grab the resource and indicate that the resource is in use by setting the semaphore value to busy If a process requests a resource that is already in use, the semaphore value indicates so, and the process must wait until the resource is freed up. The process periodically checks the status of the desired resource. Once a process is able to access the resource, the process sets the resource’s semaphore to indicate that the resource is busy with this process, and that the next process must wait until the resource is free again. Semaphores are usually binary (0 or 1 state) but can have additional values depending on the resource.

The nohup Command

When your terminal is disconnected, the kernel sends the signal SIGHUP (signal 01) to all processes that were attached to your terminal, as long as your shell does not have job control. The purpose of this signal is to have all other processes terminate. Times frequently arise, however, when you want to have a command continue execution after you hang up. For example, you will want to continue a troff process that is formatting a memorandum without having to stay logged in.

To ensure that a process stays alive after you log off, use the nohup command as follows:

 $ nohup command 

The nohup command is a built-in shell command in sh, ksh, and csh. In some earlier versions of UNIX the nohup command was a shell script that trapped and ignored the hangup signal. It basically acted like this:

 $ (trap '' 1; command) &

nohup refers only to the command that immediately follows it. If you issue a command such as

 $ nohup cat file | sort lp

or if you issue a command such as

 $ nohup date; who ; ps -ef

only the first command will ignore the hangup signal; the remaining commands on the line will die when you hang up. To use nohup with multiple commands, either precede each command with nohup or, preferably, place all commands in a file and use nohup to protect the shell that is executing the commands:

 $ cat file date who ps -ef $ nohup sh file

Zombie Processes

Normally, UNIX system processes terminate by using the exit system call. The call exit (status) returns the value of status to the parent process. When a process issues the exit call, the kernel disables all signal handling associated with the process, closes all files, releases all resources, frees any memory, assigns any children of the exiting process to be adopted by init, sends the death of a child signal to the parent process, and converts the process into the zombie state. A process in the zombie state is not alive; it does not use any resources or accomplish any work. But it is not allowed to die until the exit is acknowledged by the parent process.

If the parent does not acknowledge the death of the child (because the parent is ignoring the signal, or because the parent itself is hung), the child stays around as a zombie process. These zombie processes appear in the ps -f listing with <defunct> in place of the command:

 UID     PID   PPID  C    STIME  TTY        TIME    COMD root  21671  21577  0                      0:00    <defunct> root  21651  21577  0                      0:00    <defunct>

Because a zombie process consumes no CPU time and is attached to no terminal, the STIME and TTY fields are blank. In earlier versions of the UNIX System, the number of these zombie processes could increase and clutter up the process table. In more recent versions of the UNIX System, the kernel automatically releases the zombie processes.




UNIX. The Complete Reference
UNIX: The Complete Reference, Second Edition (Complete Reference Series)
ISBN: 0072263369
EAN: 2147483647
Year: 2006
Pages: 316

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net