Configuring kdump on the Command Line
To perform actions described in this section, you have to be logged in as a superuser:
~]$ su -
Password:
Configuring the Memory Usage
To configure the amount of memory that is reserved for the kdump kernel, open the /boot/grub/grub.conf file in a text editor and add the crashkernel= parameter to the list of kernel options as shown in Example 44.1, "A sample <size>M@16M/boot/grub/grub.conf file".
Example 44.1. A sample /boot/grub/grub.conf file
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/sda3
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Community Enterprise Linux Server (2.6.18-274.3.1.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-274.3.1.el5 ro root=/dev/sda3 crashkernel=128M@16M
initrd /initrd-2.6.18-274.3.1.el5.imgWhen the kdump crash recovery is enabled, the minimum memory requirements increase by the amount of memory reserved for it. This value is determined by a user, and defaults to 128 MB, as lower values proved to be unreliable. For more information on minimum memory requirements for Community Enterprise Linux, refer to the Required minimums section of the Community Enterprise Linux comparison chart.
Configuring the Target Type
When a kernel crash is captured, the core dump can be either stored as a file in a local file system, written directly to a device, or sent over a network using the NFS (Network File System) or SSH (Secure Shell) protocol. Note that only one of these options can be set at the moment. The default option is to store the vmcore file in the /var/crash/ directory of the local file system. To change this, open the /etc/kdump.conf configuration file in a text editor and edit the options as described below.
To change the local directory in which the core dump is to be saved, remove the hash sign ("#") from the beginning of the #path /var/crash line, and replace the value with a desired directory path. Optionally, if you wish to write the file to a different partition, follow the same procedure with the #ext3 /dev/sda3 line as well, and change both the file system type and the device (a device name, a file system label, and UUID are all supported) accordingly. For example:
ext3 /dev/sda4 path /usr/local/cores
To write the dump directly to a device, remove the hash sign ("#") from the beginning of the #raw /dev/sda5 line, and replace the value with a desired device name. For example:
raw /dev/sdb1
To store the dump to a remote machine using the NFS protocol, remove the hash sign ("#") from the beginning of the #net my.server.com:/export/tmp line, and replace the value with a valid hostname and directory path. For example:
net penguin.example.com:/export/cores
To store the dump to a remote machine using the SSH protocol, remove the hash sign ("#") from the beginning of the #net user@my.server.com line, and replace the value with a valid username and hostname. For example:
net john@penguin.example.com
Refer to OpenSSH for information on how to configure an SSH server, and how to set up a key-based authentication.
Configuring the Core Collector
To reduce the size of the vmcore dump file, kdump allows you to specify an external application (that is, a core collector) to compress the data, and optionally leave out all irrelevant information. Currently, the only fully supported core collector is makedumpfile.
To enable the core collector, open the /etc/kdump.conf configuration file in a text editor, remove the hash sign ("#") from the beginning of the #core_collector makedumpfile -c --message-level 1 line, and edit the command line options as described below.
To enable the dump file compression, add the -c parameter. For example:
core_collector makedumpfile -c
To remove certain pages from the dump, add the -d parameter, where valuevalue is a sum of values of pages you want to omit as described in Table 44.1, "Supported filtering levels". For example, to remove both zero and free pages, use the following:
core_collector makedumpfile -d 17 -c
Refer to the manual page for makedumpfile for a complete list of available options.
Table 44.1. Supported filtering levels
| Option | Description |
|---|---|
1
| Zero pages |
2
| Cache pages |
4
| Cache private |
8
| User pages |
16
| Free pages |
Changing the Default Action
By default, when kdump fails to create a core dump, the root file system is mounted and /sbin/init is run. To change this behavior, open the /etc/kdump.conf configuration file in a text editor, remove the hash sign ("#") from the beginning of the #default shell line, and replace the value with a desired action as described in Table 44.2, "Supported actions". For example:
default halt
Table 44.2. Supported actions
| Option | Action |
|---|---|
reboot
| Reboot the system, losing the core in the process. |
halt
| After failing to capture a core, halt the system. |
shell
| Run the msh session from within the initramfs, allowing a user to record the core manually. |
Enabling the Service
To start the kdump daemon at boot time, type the following at a shell prompt:
~]# chkconfig kdump on
This will enable the service for runlevels 2, 3, 4, and 5. Similarly, typing chkconfig kdump off will disable it for all runlevels. To start the service in the current session, use the following command:
~]# service kdump start
No kdump initial ramdisk found. [WARNING]
Rebuilding /boot/initrd-2.6.18-194.8.1.el5kdump.img
Starting kdump: [ OK ]
For more information on runlevels and configuring services in general, refer to Controlling Access to Services.