savecore man page on Tru64

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
Tru64 logo
[printable version]

savecore(8)							   savecore(8)

NAME
       savecore - Copies a core dump from swap partitions to a file

SYNOPSIS
       /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
       device_number:device_path...]

       /sbin/savecore  [-P]  [-mtv]  [-d  device_path]	[-d  device_path]  [-T
       device_number:device_path...]

       /sbin/savecore [prints the command line help]

OPTIONS
       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.	Causes
       the savecore command to look for the dump header in the partition spec‐
       ified  by  the  device_path  variable.  You can specify only two device
       paths. This option is useful when the dump header is stored in a parti‐
       tion  other  than  those searched by default. Normally just the primary
       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/syscon‐
       figtab 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 dif‐
       ferent 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  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 is not be the primary swap par‐
       tition.

					  Caution

	      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 explana‐
	      tion 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	parti‐
	      tion, 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: /dev/disk/disk0h

	      You  can	specify	 the  device_path option up to two times.  The
	      first time that you specify it, it is used instead of  the  cur‐
	      rent  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 sep‐
	      arated  from  the option (or options) 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  the	vmunix
	      file.   Although	space  might  appear to be insufficient, there
	      might be enough because you run the savecore  command  as	 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, estimates of available space
	      might be very conservative.  (Refer to the  DESCRIPTION  section
	      for information about the minfree file.)

	      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  manually	 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 truncated dump. Truncated dumps are  successful
	      provided	you  do not choose to compress your dump file. Trunca‐
	      tion of a compressed dump will render it useless.	 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  information).  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/sys‐
	      info.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.  Writes all crash-related files to a  remote  host.  You
	      can  specify the location where the files are written.  Alterna‐
	      tively, 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 arguments are:

	      soserv soserv:forys soserv:forys:Cr$hDeBuG  A  valid  user  name
	      (login  name)  on the remote system.  The account specified must
	      have the appropriate privileges to write the dump to its	speci‐
	      fied  location.  If  you	do not specify this argument, username
	      defaults to the string anonymous.	 The password for  the	speci‐
	      fied  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  configuration	 file.
	      For example:

	      /usr/users/monitoring/crashloc/us_support.txt

	      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 finding 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 finding and not find‐
	      ing a dump.  Supplies translations from the kernel dev_t	device
	      numbers  to file system 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 follows:

	      # 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 0x1300021.	 Displays messages  about  the
	      operation of the savecore program.

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  option,	the  savecore  program
       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 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 mem‐
       ory (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 Ker‐
       nel Debugging manual for information about analyzing crash dump files.)

					Note

       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  vmz‐
       core.0  (or  vmcore.0)  files.  It  then	 creates  a  file named direc‐
       tory/bounds and initializes the file with the value 1.  For  each  suc‐
       ceeding	crash,	the  savecore  command	uses  the  value in the direc‐
       tory/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 program copies the crash dump.	By default, this file does not
       exist,  indicating  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 direc‐
       tory/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/sys‐
       log.conf	  file.	   See	syslogd(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 configura‐
       tion files, the savecore program does not save the  corresponding  buf‐
       fer.  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,  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 loca‐
       tion 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  directory, 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
       minfree, 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 available and if the	 savecore  program  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 tem‐
       porary 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

MESSAGES
       When entered with no arguments or with illegal arguments, the  savecore
       command 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 direc‐
       tories - You specified too many directories.  unknown flag - You speci‐
       fied 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]

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 loca‐
       tion  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.

SEE ALSO
       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  vmz‐
       core(7).

       Daemons: binlogd(8), ftpd(8), and syslogd(8).

       Kernel Debugging, System Administration

								   savecore(8)
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server Tru64

List of man pages available for Tru64

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net