Enabling and Disabling Crash Dumps

During a system crash, the kernel dumps an image of its memory into a core file, which is overwritten during rebooting unless you set up the system to save it in a crash dump file. Enabling a system to save crash dumps involves:

1. Creating a crash dump directory.

2. Defining how much disk space to allow for a crash dump file.

3. Editing the sysetup file to activate the saving of crash dump files.

Disabling your system from saving crash dumps involves reversing these procedures. See "How to Disable Crash Dump Files" on page 1287 for more information.

· How to Create a Directory to Save Crash Dump Files

1. Become root.

2. Create the /var/crash directory.

# mkdir /var/crash

3. Change to the /var/crash directory.

# cd /var/crash

4. Create a directory with the name of the system.

# mkdir system-name

In this command,

system-name.....Is the system for which you want to save crash dump files.

Example--Creating a Directory to Save Crash Dump Files

The following example shows how to create a directory to save crash dump files for the system saturn.

# mkdir /var/crash # cd /var/crash # mkdir saturn

· How to Reserve Space for Crash Dump Files

1. Become root.

2. Change to the /var/crash/system-name directory.

# cd /var/crash/system-name

In this command,

system-name.....Is the system for which you want to save crash dump files.

3. Using the editor of your choice, create a file named minfree that contains a number specifying the minimum available free space (in kilobytes) that must remain available.

4. Exit the file, saving changes.

Example--Reserving Space for Crash Dump Files

The following example shows the contents of a minfree file that reserves 500 Kbytes of available free space to contain crash dump files for the system saturn.

$ more /var/crash/saturn/minfree 500

· How to Enable Crash Dump Files

1. Become root.

2. Using the editor of your choice, edit the /etc/init.d/sysetup file, activating the lines that enable the crash dumps by deleting the comment marks (#) from the beginning of those lines.

3. Exit the file, saving the changes.

Example--Enabling Crash Dump Files

The following example shows the appropriate section of the /etc/init.d/sysetup file that has been edited to enable crash dumps.

## ## Default is to not do a savecore ## If [ ! -d /var/crash/'uname -n' ] then mkdir -m 0700 -p /var/crash/'uname -n' fi echo 'checking for crash dump...\c ' savecore /var/crash/'uname -n` echo ''

· How to Disable Crash Dump Files

1. Become root.

2. Edit the /etc/init.d/sysetup file, inserting a comment mark (#) at the beginning of each of the lines shown below.

#if [ ! -d /var/crash/'uname -n' ] #then mkdir -p /var/crash/'uname -n' #fi # echo 'checking for crash dump...\c ' #savecore /var/crash/'uname -n' # echo ''

3. Save the changes.

4. Remove the file set up for crash dumps from the /var/crash directory.

# rm -rf /var/crash/system-name

In this command,

system-name.....Is the name of the system which will no longer save crash dump files.

Viewing System Information Generated by a Crash

When a system crashes, it displays a message like this:

panic: error message

where error message is one of the panic error messages described in the crash(1M) man page.

Less frequently, this message may be displayed instead of the panic message:

Watchdog reset !

System messages like these are automatically stored in /var/adm/messages (or /usr/adm/messages) throughout the session. These messages are saved whether or not crash dumps are enabled for a system.

The /var/adm directory contains several message files. The most recent messages are in /var/adm/messages (and in messages.0), and the oldest are in messages.3. After a period of time (usually every ten days), a new messages file is created. The file messages.0 is renamed messages.1, messages.1 is renamed messages.2, and messages.2 is renamed messages.3. The current /var/adm/messages.3 is deleted.

You can examine the control structures, active tables, memory images of a live or crashed system kernel, and other information about the operation of the kernel using the crash utility. Additionally, crash dumps saved by crash can be useful to send to a customer service representative for analysis. Using crash to its full potential requires a detailed knowledge of the kernel, and is beyond the scope of this manual. For more details on the operation of the crash utility, see the crash(1M) manual page.

· How to View Crash and Boot Messages

Display messages generated by a system crash or booting by using the dmesg command.

$ dmesg

Or use the more command to display one screen of messages at a time.

$ more /var/adm/messages

For more information, refer to the dmesg(1M) man page.

Example--Viewing Crash and Boot Messages

The following example shows output from the dmesg command.

$ dmesg Mar 29 15:11 SunOS Release 5.5 Version A [UNIX(R) System V Release 4.0] copyright (c) 1983-1995, Sun Microsystems, Inc. DEBUG enabled WARNING: cannot load psm xpcimach mem = 32376K (0x1f9e000) avail mem = 25247744 root nexus = i86pc Unable to install/attach drive 'isa' eisa0 at root NOTICE: eisa: DMA buffer-chaining not enabled NOTICE: IN i8042_acquire NOTICE: out i8042_acquire NOTICE: IN i8042_release NOTICE: about to enable keyboard NOTICE: out i8042_release . . .

· How to Examine a Crash Dump

To examine crash dumps, use the crash utility.

# /usr/sbin/crash [-d crashdump-file] [-n name-list] [-w output-file]

In this command,

-d crashdump-file	Specifies a file to contain the system memory image. The default crash dump file is /dev/mem.
-n name-list	Specifies a text file to contain symbol table information if you want to examine symbolic access to the system memory image. The default file name is /dev/ksyms.
-w output-file	Specifies a file to contain output from a crash session. The default is standard output.

Example--Examining a Crash Dump

The following example shows sample output using the crash utility. Information about status, and buffer, process, and queue size is displayed.

# /usr/sbin/crash dumpfile = /dev/mem, namelist = /dev/ksyms, outfile = stdout > status system name: SunOS release: 5.5 node name: saturn version: test machine name: i86pc time of crash: Wed Mar 29 16:48:06 1995 age of system: 9 day, 2 hr., 52 min. panicstr: panic registers: eip: 0 esp: 0 > size buf proc queue 116 1580 88

Customizing System Logging

You can capture error messages that are generated by various system processes by editing the /etc/syslog.conf file to set up system logging.

The /etc/syslog.conf file has two columns separated by tabs. The first column specifies the source of the error condition and its priority. The second column specifies the place where the errors are logged. The following example shows sample lines from an /etc/syslog.conf file.

user.alert /dev/console kern.err /var/adm/messages

The message sources in the first column are specified by two parts separated by a dot (.). The first part is the source or facility, which describes the part of the system generating the message. The second part is the priority of the message. The most common sources are shown in Table 64-1. The most common priorities are shown in Table 64-2 in order of severity.

Table 64-1 syslog.conf

Source	Description
kern	The kernel
auth	Authentication
daemon	All daemons
mail	Mail system
lp	Spooling system
user	User processes

---

Note - A maximum of 24 syslog sources (or facilities) can be activated in the /etc/syslog.conf file.

---

Table 64-2 syslog.conf

Priority	Description
emerg	System emergencies
alert	Error requires immediate correction
crit	Critical errors
err	Other errors
info	Informational messages
debug	Output used for debugging
none	Setting that doesn't log output

By default, /etc/syslog.conf directs many system process messages to the /var/adm message files. Crash and boot messages are stored here as well. To view /var/adm messages, see "How to View Crash and Boot Messages" on page 1288.

· How to Customize System Logging

1. Become root.

2. Using the editor of your choice, edit the /etc/syslog.conf file, adding or changing message sources, priorities, and message locations according to the syntax described in "Customizing System Logging" on page 1291.

3. Exit the file, saving the changes.

Example--Customizing System Logging

The following sample lines from the /etc/syslog.conf file that is provided during Solaris installation show that, by default, user errors are printed to the console and also are logged to the file /var/adm/messages.

Mail debugging output is logged to the file /var/log/syslog.

user.err /dev/console user.err /var/adm/messages user.alert 'root, operator' mail.debug /var/log/syslog