savecore - Copies a core dump from swap partitions to a file
/sbin/savecore [-efmnstv] [-d device_path] [-d device_path] [directory] [-r
ftpspec | cfgfile] [-T device_number:device_path...]
/sbin/savecore [-c] [-mv] [-d device_path] [-d device_path] [-T
/sbin/savecore [-P] [-mtv] [-d device_path] [-d device_path] [-T
/sbin/savecore [prints the command line help]
Clears any core dumps from the swap partitions without saving the dump.
Because nothing is saved, there is no need to specify the directory in
which to save the core file. Only the -d and -v options can be used in
combination with the -c option. See also the -P (print) option.
-d device_path (device)
Causes the savecore command to look for the dump header in the parti-
tion specified by the device_path variable. You can specify only two
device paths. This option is useful when the dump header is stored in a
partition other than those searched by default. Normally just the pri-
mary swap partition is searched. You might want the savecore command
to search elsewhere if you expect the dump header to be in a different
location, for example:
+ You changed the way that swap partitions are assigned in the
/etc/fstab , /sbin/swapdefault , or the /etc/sysconfigtab file,
but, at the time of the crash, you had yet to force the swapper to
conform to the settings.
+ Your system crashed while running with the root directory on one
drive, and you rebooted and are running the savecore command with
the root directory on another drive with different swap partition
assignments. In this case the savecore command copies the wrong
vmunix file to directory/vmunix.n , and you must replace it with a
copy of the correct vmunix file from the root device that
+ The primary swap device had soft failed before the crash (possibly
causing the crash), and the dump code placed the header on the
first working swap device, which is not be the primary swap parti-
The dumpdev kernel variable is defunct. This variable specifies the
dev_t of a partition in which the savecore command should look for a
header by default. (See the -T option for an explanation of dev_t.)
Avoid using the dumpdev variable and verify that it is not set. If
the dumpdev variable is set to a partition other than the primary
swap partition, you might forget to change that setting if you later
configure the partition to hold a file system instead of swap space.
If this happens and the system crashes, the dump is written on the
file system partition, destroying your data.
The device path (device_path) is interpreted relative to the current
directory when the savecore command is invoked. Since disk partitions
are usually found in the /dev directory or in subdirectories thereof,
you must supply the full pathname of the partition, such as:
You can specify the device_path option up to two times. The first time
that you specify it, it is used instead of the current dumpdev setting.
(The current setting is retrieved using the getsysinfo(GSI_DUMPDEV)
function.) The second time that you specify the device_path variable,
it is used in place of the primary swap partition. Note that the
specification must be separated from the option (or options) by whi-
-e (error logs)
Saves only the kernel message buffer and binary event log buffers from
the dump. Other information in the crash dump, such as the copy of
physical memory, is not saved.
Copies the dump even if there appears to be insufficient storage space
on the specified filesystem to save both the dump and the copy of the
vmunix file. Although space might appear to be insufficient, there
might be enough because you run the savecore command as superuser. This
enables the savecore program to use space normally reserved to help
control fragmentation. Also, if the specified directory contains a
minfree file, estimates of available space might be very conservative.
(Refer to the DESCRIPTION section for information about the minfree
The dump file might fit in the available space, but the copy of vmunix
might not. To recover from this, run the /usr/bin/crashdc command manu-
ally and specify the actual location of the vmunix file.
If the dump itself does not fit, then only the portion of the dump that
fits in the space available is copied and it is referred to as a trun-
cated dump. Truncated dumps are successful provided you do not choose
to compress your dump file. Truncation of a compressed dump will render
-m (no memory check)
Prevents the savecore command from checking for the existence of an
in-memory core dump. When you specify -m, the savecore command does
not attempt to open the /dev/vmzcore file but only checks the default
or specified (-d) disk partitions. (See vmzcore(7) for more informa-
-n (no clear)
Prevents the savecore program from clearing the dump header out of the
partitions in which it was found (after saving the dump, and/or message
buffer and binary event log). This is intended as a debugging option
but it allows you to run the savecore command once with the -e and -n
options, and then with the -s option and a different directory.
Searches for a crash dump and, if found, displays its dumpinfo header.
The dump header structure is defined in the /usr/include/sys/sysinfo.h
file. No directory need be specified since nothing is saved. After
displaying the header, the savecore utility exits, leaving any existing
crash dump intact. See also the -c (clear) option.
-r ( ftpspec | cfgfile ) (remote)
Writes all crash-related files to a remote host. You can specify the
location where the files are written. Alternatively, you can specify
the absolute path to a file containing the location. The -r option
accepts an argument in the following syntax:
host[:username][:password]] | cfgfile
This argument is defined as follows:
If you specify the location for the crash dump, you must also specify a
minimum path, which is the name of a remote host. Specify the fully
qualified host name, the unqualified name, or the TCP/IP address of the
remote host. When you specify a host name, you can truncate the loca-
tion argument before either of the colons (:). For example, valid argu-
A valid user name (login name) on the remote system. The account
specified must have the appropriate privileges to write the dump to its
specified location. If you do not specify this argument, username
defaults to the string anonymous.
The password for the specified username. If you do not specify this
argument, password defaults to the string savecore@.
If you do not specify a remote host (and optionally a user name and
password), you can instead specify an absolute pathname to a configura-
tion file. For example:
Savecore reads FTP Connection information from the cfgfile file. This
file is an ASCII text file containing only the ftpspec argument. It
enables you to keep the remote account name and password secret.
Prevents the savecore program from saving the message buffer and binary
event log, and prevents copying of the vmunix file.
Produces an exit value of 4 when no dump is found. Normally, not find-
ing a dump is not considered an error, and the default exit value is 0.
The exit value is also 0 when a dump is saved successfully. Scripts
such as /sbin/init.d/savecore depend upon this behavior. You can use
the -t option to write scripts which need to distinguish between find-
ing and not finding a dump.
-T device_number:device_path (translate)
Supplies translations from the kernel dev_t device numbers to file sys-
tem device paths. Any number of translations can be specified and each
must be preceded by the -T option. This option is required only when
the saved device number(s) do not match the file system devices on
which the crash dump was written. For example, The following option
maps device number x13007f3 to disk partition /dev/disk/dsk0b:
You can obtain the value used for the device_number variable by using
the ls command with the device special file for a disk partition, as
# ls -l /dev/disk/dsk0a
brw------- 1 root system 19, 33 Oct 20 1999 /dev/disk/dsk0a
The numbers 19, 33 in the output are the major and minor numbers of the
device. These two numbers are combined into a single 32-bit integer to
form the device number. In this case, 0x13 and 0x21 become number
Displays messages about the operation of the savecore program.
The savecore command is usually invoked automatically during system
startup. It determines whether a crash dump has been made, and if there is
enough file system space to save it (see the following information about
minfree). If you specify the -f option, the savecore program copies the
dump even if there seems to be insufficient file space. If space is insuf-
ficient, only a portion of the dump is saved into the crash dump file as a
truncated dump. If compressed, truncated dumps are not usable. Information
is stored in the /var/adm/crash directory by default.
The crash dump contains the copy of a selected portion of physical memory
(or all of physical memory in the case of a full crash dump) as of the time
of the crash. The savecore command saves this information in the vmzcore.n
file if the dump is in the compressed form, or in the vmcore.n file if in
the noncompressed form. The command also copies the kernel executable
image, usually /vmunix, (or whatever UNIX image filename was recorded as
the name of the booted file) to the /var/adm/crash/vmunix.n file. You
analyze the vmzcore.n (or vmcore.n) and vmunix.n files to determine the
cause of the crash. (See the Kernel Debugging manual for information about
analyzing crash dump files.)
In the case of a boot-linked kernel, which has no image file to copy,
the linker is invoked to create one from suitable modules.
In the dump filename, the n variable indicates the sequential number of the
crash. For the first crash, savecore creates the vmunix.0 and vmzcore.0 (or
vmcore.0) files. It then creates a file named directory/bounds and ini-
tializes the file with the value 1. For each succeeding crash, the savecore
command uses the value in the directory/bounds file and then increments
The directory/minfree file specifies the minimum number of kilobytes that
must remain on the filesystem containing directory after the savecore pro-
gram copies the crash dump. By default, this file does not exist, indicat-
ing that the minimum number of kilobytes is zero. To specify a minimum,
create the file and store the number of kilobytes you want reserved in it.
You can override the setting in directory/minfree using the -f option.
In addition to saving the crash dump, the savecore program writes a reboot
message to the /var/adm/syslog/auth.log file. If the system crashed as a
result of a panic, savecore includes the panic string in that log file. You
can cause the savecore program to write the message to another file by
modifying the auth facility entry in the /etc/syslog.conf file. See sys-
logd(8) for information about modifying the/etc/syslog.conf file.
The savecore command also attempts to save the kernel message buffer and
binary event log buffers from the dump. The kernel message buffer is saved
in the /var/adm/crash/msgbuf.savecore file by default. The binary event
log buffer is saved in the /var/adm/crash/binlogdumpfile file by default.
When the syslog and binlog daemons are initialized later during system
startup, they check for the saved buffer files. The daemons process and
delete the files.
You can change the location to which the savecore program writes the kernel
message buffer and binary event log. To change the location for saving the
kernel message buffer, modify the msgbuf.err entry in the /etc/syslog.conf
file. To change the location for saving the binary event log, modify the
dumpfile entry in the /etc/binlog.conf file. If you remove either the
msgbuf.err or dumpfile entry from the configuration files, the savecore
program does not save the corresponding buffer. For most entries, the
/etc/syslog.conf and /etc/binlog.conf files allow you to forward messages
to another system. However, you cannot specify a forwarding address in the
msgbuf.err and dumpfile entries. For more information, see syslogd(8) and
The default location for saving crash dump files is /var/adm/crash. To
modify the default location, issue the following command:
> /usr/sbin/rcmgr set SAVECORE_DIR <directory>
By default, the savecore program returns to single-user mode if it is
unable to save a core dump because of insufficient filesystem space. You
can disable this feature as follows:
/usr/sbin/rcmgr set SAVECORE_FLAGS M
Saving Crash Dump Files to a Remote Host
The -r option enables you to write crash dump files to a remote location
using an ftp connection.
When it connects to the target host, the savecore program directs the
remote ftpd server to create a directory named after the client host name.
(See ftpd(8) for more information.) After changing to this remote direc-
tory, a bounds file is read (or created if it does not yet exist), and all
crash-related files are deposited therein. The crash dump files (bounds,
msgbuf.savecore, evm.buf, vmunix.N and vmcore.N or vmzcore.N) are written
to the directory.
You must ensure that you have adequate space for the crash dump on the
remote device. In remote mode, the savecore program does not support min-
free, because there is no way to obtain disk capacity using FTP.
If a remote save is initialized during the boot process and the remote host
is unavailable for any reason, the ftp process will time out. As an aid to
debugging a connection, you can use the -v (verbose) option to display the
ongoing FTP transaction.
EVM Events in the Crash Dump
The system might crash before all kernel events are handled and posted. In
such cases, the savecore program recovers such events and stores them for
later processing. This action happens only if any such events are avail-
able and if the savecore program is able to successfully extract and save
By default, the events are stored in the following file:
This file contains a sequence of events, each with a header and body. If no
file is created then it is likely that there were no kernel events unpro-
cessed at the time of the crash. The evm.buf file is temporary and is
automatically deleted after it is processed.
On restart, the EVM daemon determines if the evm.buf file exists. If the
file exists, the evmd daemon reads it and distributes the events to any
subscribers. You can view the events using the graphical evmviewer utility
or the EVM command-line utilities evmget and evmshow.
You can specify the location of the event file by adding the following line
to the /etc/evmdaemon.conf file:
When entered with no arguments or with illegal arguments, the savecore com-
mand displays the following help information:
savecore: usage: -<FLAGS> [<directory>]
Valid <FLAGS> depend on operation:
savecore -c [-mv]
savecore -P [-mtv]
savecore [-efmnstv] ( <directory> | -r <ftpspec> )
All variants also permit the specification of
alternate dump partitions (-d) and additional
device number/path translations (-T) using:
[-d <device_path> -d <device_path>]
[-T <device_number>:<device_path> ...]
If you enter an illegal command, the help information is preceded by the
savecore: invalid argument: error_string
Where the error_string variable is one of the following messages:
+ extraneous directory - A directory is not required for this command.
+ missing directory - You must specify a directory path.
+ multiple directories - You specified too many directories.
+ unknown flag - You specified an illegal command option.
The following messages indicate that you specified illegal arguments or
illegal combinations of command options:
-P may only include -[tvTd]
-T format is incorrect
-T memory allocation failed
-T requires a parameter
-d may only be specified twice
-c may only include -[vTd]
Specifies the executable file.
Specifies the number of the filename for the next dump.
Specifies the minimum number of kilobytes to be left after crash dump
files are written.
System logging configuration file.
Binary logging configuration file.
Default location of the dump file and the vmunix.n copy.
The default location of the file in which the crashed system's kernel
message buffer is saved.
The default location of the file in which the crashed system's binary
event log buffer is saved.
The default location of the file in which unposted kernel EVM events
Commands: dumpsys(8), EVM(5), evmd(8), evmget(1), evmshow(1), evmviewer(8),
Files: binlog.conf(4), evmdaemon.conf(4), syslog.conf(4), and vmzcore(7).
Daemons: binlogd(8), ftpd(8), and syslogd(8).
Kernel Debugging, System Administration