Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Apropos / Subsearch:
optional field

savecore(8)							  savecore(8)


  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]


  -c (clear)
      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.

  -f  (force)
      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
      it useless.

  -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.

  -P (print)
      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-
      ments are:


      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.

  -s (simple)
      Prevents the savecore program from saving	the message buffer and binary
      event log, and prevents copying of the vmunix file.

  -t (tell)
      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:

	   -T 0x13007f3:/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

  -v (verbose)
      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
  that value.

  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
  the events.

  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:

       crash_dumpfile	       your_file_name


  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
  following message:

  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
      are saved.


  Commands: dumpsys(8),	EVM(5),	evmd(8), evmget(1), evmshow(1),	evmviewer(8),
  expand_dump(8),and rcmgr(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