23.2.3. Configuring kdump on the Command Line
23.2.3.1. Configuring the Memory Usage
To configure the amount of memory that is reserved for the kdump
kernel, as root
, edit the /etc/default/grub
file and add the crashkernel=<size>
M
(or crashkernel=auto
) parameter to the list of kernel options (the GRUB_CMDLINE_LINUX
line). For example, to reserve 128 MB of memory, use:
GRUB_CMDLINE_LINUX="crashkernel=128M
quiet rhgb"
Then update the configuration file for the GRUB 2 boot loader by typing the following at a shell prompt as root
:
grub2-mkconfig
-o
/boot/grub2/grub.cfg
Unless the system has enough memory, this option will not be available. For the information on minimum memory requirements, refer to the
Hardware Overview section of the
Fedora 17 Release Notes. 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 the user, and defaults to 128 MB plus 64 MB for each TB of physical memory (that is, a total of 192 MB for a system with 1 TB of physical memory).
In Fedora 17, the crashkernel=auto
only reserves memory if the system has 4 GB of physical memory or more.
23.2.3.2. 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. Only one of these options can be set at the moment, and the default option is to store the vmcore
file in the /var/crash/
directory of the local file system. To change this, as root
, 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 #ext4 /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
Chapter 10, OpenSSH for information on how to configure an SSH server, and how to set up a key-based authentication.
23.2.3.3. 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, as root
, 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 -d 31
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 value
parameter, where
value
is a sum of values of pages you want to omit as described in
Table 23.2, “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 23.2. Supported filtering levels
Option
|
Description
|
---|
1
|
Zero pages
|
2
|
Cache pages
|
4
|
Cache private
|
8
|
User pages
|
16
|
Free pages
|
23.2.3.4. 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, as
root
, 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 23.3, “Supported actions”.
Table 23.3. Supported actions
Option
|
Description
|
---|
reboot
|
Reboot the system, losing the core in the process.
|
halt
|
Halt the system.
|
poweroff
|
Power off the system.
|
shell
|
Run the msh session from within the initramfs, allowing a user to record the core manually.
|
For example:
default halt
23.2.3.5. Enabling the Service
To start the kdump
daemon at boot time, type the following at a shell prompt as root
:
systemctl
enable
kdump.service
Similarly, typing systemctl disable kdump.service
will disable it. To start the service in the current session, use the following command as root
:
systemctl
start
kdump.service