2020-10-15 12:45:57 +00:00
|
|
|
.TH KDUMPCTL 8 2015-07-13 kexec-tools
|
|
|
|
|
|
|
|
|
|
.SH NAME
|
|
|
|
|
kdumpctl \- control interface for kdump
|
|
|
|
|
|
|
|
|
|
.SH SYNOPSIS
|
|
|
|
|
.B kdumpctl
|
|
|
|
|
.I COMMAND
|
|
|
|
|
|
|
|
|
|
.SH DESCRIPTION
|
|
|
|
|
.B kdumpctl
|
|
|
|
|
is used to check or control the kdump service.
|
|
|
|
|
In most cases, you should use
|
|
|
|
|
.B systemctl
|
|
|
|
|
to start / stop / enable kdump service instead. However,
|
|
|
|
|
.B kdumpctl
|
2022-05-11 02:27:42 +00:00
|
|
|
provides more details for debugging and a helper to set up ssh key authentication.
|
2020-10-15 12:45:57 +00:00
|
|
|
|
|
|
|
|
.SH COMMANDS
|
|
|
|
|
.TP
|
|
|
|
|
.I start
|
|
|
|
|
Start the service.
|
|
|
|
|
.TP
|
|
|
|
|
.I stop
|
|
|
|
|
Stop the service.
|
|
|
|
|
.TP
|
|
|
|
|
.I status
|
|
|
|
|
Prints the current status of kdump service.
|
2022-05-11 02:27:42 +00:00
|
|
|
It returns a non-zero value if kdump is not operational.
|
2020-10-15 12:45:57 +00:00
|
|
|
.TP
|
|
|
|
|
.I restart
|
|
|
|
|
Is equal to
|
|
|
|
|
.I start; stop
|
|
|
|
|
.TP
|
|
|
|
|
.I reload
|
2022-05-11 02:27:42 +00:00
|
|
|
reload the crash kernel image and initramfs without triggering a rebuild.
|
2020-10-15 12:45:57 +00:00
|
|
|
.TP
|
|
|
|
|
.I rebuild
|
|
|
|
|
rebuild the crash kernel initramfs.
|
|
|
|
|
.TP
|
|
|
|
|
.I propagate
|
|
|
|
|
Helps to setup key authentication for ssh storage since it's
|
|
|
|
|
impossible to use password authentication during kdump.
|
|
|
|
|
.TP
|
|
|
|
|
.I showmem
|
2022-05-11 02:27:42 +00:00
|
|
|
Prints the size of reserved memory for the crash kernel in megabytes.
|
2021-04-21 19:27:10 +00:00
|
|
|
.TP
|
|
|
|
|
.I estimate
|
2022-05-11 02:27:42 +00:00
|
|
|
Estimate a suitable crashkernel value for the current machine. This is a
|
|
|
|
|
best-effort estimate. It will print a recommended crashkernel value
|
|
|
|
|
based on the current kdump setup, and list some details of memory usage.
|
|
|
|
|
.TP
|
|
|
|
|
.I get-default-crashkernel
|
|
|
|
|
Return the default crashkernel value provided by kexec-tools.
|
2021-06-10 05:06:22 +00:00
|
|
|
.TP
|
2022-01-05 03:53:09 +00:00
|
|
|
.I reset-crashkernel [--kernel=path_to_kernel] [--reboot]
|
|
|
|
|
Reset crashkernel to default value recommended by kexec-tools. If no kernel
|
|
|
|
|
is specified, will reset KDUMP_KERNELVER if it's defined in /etc/sysconfig/kdump
|
2022-05-11 02:27:42 +00:00
|
|
|
or the current running kernel's crashkernel value if KDUMP_KERNELVER is empty. You can
|
2022-01-05 03:53:09 +00:00
|
|
|
also specify --kernel=ALL and --kernel=DEFAULT which have the same meaning as
|
|
|
|
|
grubby's kernel-path=ALL and kernel-path=DEFAULT. ppc64le supports FADump and
|
2022-05-11 02:27:42 +00:00
|
|
|
supports an additional [--fadump=[on|off|nocma]] parameter to toggle FADump
|
2022-01-05 03:53:09 +00:00
|
|
|
on/off.
|
2021-06-10 05:06:22 +00:00
|
|
|
|
2024-07-11 09:48:37 +00:00
|
|
|
If the optional parameter [--reboot] is provided the system will automatically
|
|
|
|
|
reboot for changes to take effect. If no changes were made to the kernel
|
|
|
|
|
command line the reboot is omitted.
|
|
|
|
|
|
2022-01-05 03:53:09 +00:00
|
|
|
Note: The memory requirements for kdump varies heavily depending on the
|
|
|
|
|
used hardware and system configuration. Thus the recommended
|
|
|
|
|
crashkernel might not work for your specific setup. Please test if
|
|
|
|
|
kdump works after resetting the crashkernel value.
|
Introduce vmcore creation notification to kdump
Upstream: fedora
Resolves: RHEL-32060
Conflict: Yes, there are several conflicts. 1) Upstream have moved
dracut-kdump.sh into kdump-utils/dracut/99kdumpbase/kdump.sh,
so the targeting files are changed. 2) There are several
patchsets([1] [2]) which not backported to rhel9, so some
formating conflicts encountered. But there is no functional
change been made for the patch backporting.
[1]: https://github.com/rhkdump/kdump-utils/pull/18/commits
[2]: https://github.com/rhkdump/kdump-utils/pull/33/commits
commit 88525ebf5e43cc86aea66dc75ec83db58233883b
Author: Tao Liu <ltao@redhat.com>
Date: Thu Sep 5 15:49:07 2024 +1200
Introduce vmcore creation notification to kdump
Motivation
==========
People may forget to recheck to ensure kdump works, which as a result, a
possibility of no vmcores generated after a real system crash. It is
unexpected for kdump.
It is highly recommended people to recheck kdump after any system
modification, such as:
a. after kernel patching or whole yum update, as it might break something
on which kdump is dependent, maybe due to introduction of any new bug etc.
b. after any change at hardware level, maybe storage, networking,
firmware upgrading etc.
c. after implementing any new application, like which involves 3rd party modules
etc.
Though these exceed the range of kdump, however a simple vmcore creation
status notification is good to have for now.
Design
======
Kdump currently will check any relating files/fs/drivers modified before
determine if initrd should rebuild when (re)start. A rebuild is an
indicator of such modification, and kdump need to be rechecked. This will
clear the vmcore creation status specified in $VMCORE_CREATION_STATUS.
Vmcore creation check will happen at "kdumpctl (re)start/status", and will
report the creation success/fail status to users. A "success" status indicates
previously there has been a vmcore successfully generated based on the current
env, so it is more likely a vmcore will be generated later when real crash
happens; A "fail" status indicates previously there was no vmcore
generated, or has been a vmcore creation failed based on current env. User
should check the 2nd kernel log or the kexec-dmesg.log for the failing reason.
$VMCORE_CREATION_STATUS is used for recording the vmcore creation status of
the current env. The format will be like:
success 1718682002
Which means, there has been a vmcore generated successfully at this
timestamp for the current env.
Usage
=====
[root@localhost ~]# kdumpctl restart
kdump: kexec: unloaded kdump kernel
kdump: Stopping kdump: [OK]
kdump: kexec: loaded kdump kernel
kdump: Starting kdump: [OK]
kdump: Notice: No vmcore creation test performed!
[root@localhost ~]# kdumpctl test
[root@localhost ~]# kdumpctl status
kdump: Kdump is operational
kdump: Notice: Last successful vmcore creation on Tue Jun 18 16:39:10 CST 2024
[root@localhost ~]# kdumpctl restart
kdump: kexec: unloaded kdump kernel
kdump: Stopping kdump: [OK]
kdump: kexec: loaded kdump kernel
kdump: Starting kdump: [OK]
kdump: Notice: Last successful vmcore creation on Tue Jun 18 16:39:10 CST 2024
The notification for kdumpctl (re)start/status can be disabled by
setting VMCORE_CREATION_NOTIFICATION in /etc/sysconfig/kdump
Signed-off-by: Tao Liu <ltao@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
2024-10-08 01:48:04 +00:00
|
|
|
.TP
|
|
|
|
|
.I test [--force]
|
|
|
|
|
Test the kdump by actually trigger the system crash & dump, and check if a
|
|
|
|
|
vmcore can really be generated successfully based on current config and
|
|
|
|
|
environment. After system reboot back to normal, check the test result
|
|
|
|
|
by "kdumpctl status".
|
|
|
|
|
|
|
|
|
|
If the optional parameter [--force] is provided, there will be no interact
|
|
|
|
|
before triggering the system crash. Dangerous though, this option is meant
|
|
|
|
|
for automation testing.
|
2020-10-15 12:45:57 +00:00
|
|
|
|
|
|
|
|
.SH "SEE ALSO"
|
|
|
|
|
.BR kdump.conf (5),
|
|
|
|
|
.BR mkdumprd (8)
|
