Advanced Programming in the UNIX® Environment

ptg10805159

Section 10.2 Signal Concepts 315

We can tell the kernel to do one of three things when a signal occurs. We call this

thedispositionof the signal, or theactionassociated with a signal.

1. Ignorethe signal. This works for most signals, but two signals can never be
   ignored:SIGKILLandSIGSTOP.The reason these two signals can’t be ignored
   is to provide the kernel and the superuser with a surefireway of either killing or
   stopping any process. Also, if we ignoresome of the signals that aregenerated
   by a hardwareexception (such as illegal memory reference or divide by 0), the
   behavior of the process is undefined.


2. Catch the signal. To dothis, we tell the kernel to call a function of ours
   whenever the signal occurs. In our function, we can do whatever we want to
   handle the condition. If we’rewriting a command interpreter,for example,
   when the user generates the interrupt signal at the keyboard, we probably want
   to return to the main loop of the program, terminating whatever command we
   wereexecuting for the user.IftheSIGCHLDsignal is caught, it means that a
   child process has terminated, so the signal-catching function can callwaitpid
   to fetch the child’s process ID and termination status. As another example, if
   the process has created temporary files, we may want to write a signal-catching
   function for theSIGTERMsignal (the termination signal that is the default signal
   sent by thekillcommand) to clean up the temporary files. Note that the two
   signalsSIGKILLandSIGSTOPcan’t be caught.


3. Let the default action apply.Every signal has a default action, shown in
   Figure10.1. Note that the default action for most signals is to terminate the
   process.

Figure10.1 lists the names of all the signals, an indication of which systems support the

signal, and the default action for the signal. The SUS column contains • if the signal is

defined as part of the base POSIX.1 specification andXSIif it is defined as part of the

XSI option.

When the default action is labeled ‘‘terminate+core,’’ it means that a memory image

of the process is left in the file namedcoreof the current working directory of the

process. (Because the file is namedcore, it shows how long this featurehas been part

of the UNIX System.) This file can be used with most UNIX System debuggers to

examine the state of the process at the time it terminated.

The generation of thecorefile is an implementation feature of most versions of the UNIX

System. Although this feature is not part of POSIX.1, it is mentioned as a potential

implementation-specific action in the Single UNIX Specification’s XSI option.

The name of the corefile varies among implementations. On FreeBSD 8.0, for example, the

corefile is namedcmdname.core, wherecmdnameis the name of the command corresponding to

the process that received the signal. On Mac OS X 10.6.8, the corefile is named core.pid,where

pidis the ID of the process that received the signal. (These systems allow the corefilename to

be configured via asysctlparameter.OnLinux 3.2.0, the name is configured through

/proc/sys/kernel/core_pattern.)

Most implementations leave the corefile in the current working directory of the corresponding

process; Mac OS X places all corefiles in/coresinstead.