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.img
When 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 value
value
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.