Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

savecore(8) [osf1 man page]

savecore(8)						      System Manager's Manual						       savecore(8)

savecore - Copies a core dump from swap partitions to a file SYNOPSIS
/sbin/savecore [-efnpPstv] directory /sbin/savecore [-d header-dev [-d header-dev]] directory /sbin/savecore -c /sbin/savecore -T devno:devpath OPTIONS
Clears any core dumps from the swap partitions without saving the dump. As nothing is saved, there is no need to specify the directory in which to save the core file. Only the -d and -v flags can be used in combination with the -c flag. See also the -P (print) option. Causes the savecore command to look for the dump header in the partition specified by header-dev. This option is useful when the dump header is stored in a partition other than those searched by default. Normally just the primary swap partition is searched. You might want savecore to search elsewhere if you expect the dump header to be in a different location, for example: You changed the way that swap parti- tions are assigned in the /etc/fstab, /sbin/swapdefault, and/or /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 root on one drive, but have rebooted and are running savecore with root on another drive with different swap partition assignments. (Note that in this case savecore copies the wrong vmunix to directory/vmunix.n, and you must replace it with a copy of the correct vmunix file from the root that crashed.) 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 will not be the primary swap partition. The dumpdev kernel variable is defunct. This variable specifies the dev_t of a partition in which savecore should look for a header by default. Avoid using the dumpdev variable and verify that it is not set. Should the dumpdev variable be set to a partition other than primary swap, 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 header-dev is interpreted relative to the current directory when savecore is invoked. Since disk partitions are usually found in /dev or in subdirectories thereof, you must supply the full pathname of the partition, such as: /dev/disk/disk0h It is meaningful to specify this flag up to two times. The first time that it is specified, it is used instead of the dumpdev set- ting found via getsysinfo(GSI_DUMPDEV). The second time that it is specified, it is used in place of the primary swap partition. Note that the specification must be separated from the flag (or flags) by whitespace. 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 vmunix file. Although space might appear to be insufficient, there might be enough because you run savecore as root (supe- ruser). This enables the savecore program to use space normally reserved to help control fragmentation. Also, if the specified directory contains a minfree file (see below) estimates of available space might be very conservative. It may be that the dump fits in the available space, but the copy of vmunix does not. You can recover from this by running /usr/bin/crashdc manually and specifying 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. Such a truncated dump can often work if it is not compressed. Truncation of a compressed dump will render it useless. 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 flag but it allows you to run savecore once with the -e and -n flags, and then with the -s flag and a different directory. Produces printouts of interest only to a developer. The -p option is used when debugging the dump system. 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. 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 finding a dump is not considered an error, and the default exit value is 0. It 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 finding and not finding a dump. 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: -T 0x13007f3:/dev/disk/dsk0b Displays messages about the operation of savecore. DESCRIPTION
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 flag, savecore copies the dump even if there seems to be insufficient file space. If space is insufficient, only a portion of the dump is saved into the crash dump file but note that truncated compressed dumps will not be 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 file vmzcore.n if the dump is in the compressed form, or in the file vmcore.n 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 will be invoked to create one from suitable modules. In the dump filename, the variable n indicates the sequential number of the crash. For the first crash, savecore creates the files vmu- nix.0 and vmzcore.0 (or vmcore.0). It then creates a file named directory/bounds and initializes the file with the value 1. For each succeeding crash, the savecore command uses the value in the directory/bounds file and then increments that value. The directory/minfree file specifies the minimum number of kilobytes that must be left on the filesystem containing directory after savecore copies the crash dump. By default, this file does not exist, indicating that the minimum 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 flag. In addition to saving the crash dump, the savecore command 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 savecore to write the message to another file by modifying the auth facility entry in the /etc/syslog.conf file. See the syslogd(8) reference page for information about modifying /etc/syslog.conf. 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/binlogdump- file 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 savecore 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, savecore 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 binlogd(8). 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, savecore returns to single-user mode if it is unable to save a core dump because of insufficient filesystem space. This feature can be disabled as follows: /usr/sbin/rcmgr set SAVECORE_FLAGS M EVM Events in the Crash Dump The system might crash before all kernel events are handled and posted. In such cases, savecore recovers such events and stores them for later processing. This action happens only if any such events are available and if savecore is able to successfully extract and save the events. By default, the events are stored in the following file: /var/adm/crash/evm.buf 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 unprocessed 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, evmd reads it and distributes the events to any sub- scribers. 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: crash_dump- file your_file_name FILES
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 are saved. RELATED INFORMATION
Commands: binlog.conf(4), EVM(5), evmd(8), evmget(1), evmshow(1), evmviewer(8), evmdaemon.conf(4), dumpsys(8), expand_dump(8), rcmgr(8), and syslog.conf(4). Daemons: binlogd(8), syslogd(8) Kernel Debugging, System Administration delim off savecore(8)
Man Page

Featured Tech Videos