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.
|
Re-introduce vmcore creation notification to kdump
Upstream: fedora
Resolves: RHEL-70214
Conflict: Yes, the conflict is the same as the original c9s commit
c5aa4609 ("Introduce vmcore creation notification to kdump")
9ec61f6c ("Return the correct exit code of rebuild initrd")
Also this patch cherry-picked the ipv6 fixed in [1].
[1]: https://github.com/rhkdump/kdump-utils/pull/60/files
commit 24e76222c740def1d03a506652400fe55959e024
Author: Tao Liu <ltao@redhat.com>
Date: Fri Nov 29 16:15:18 2024 +1300
Re-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 test 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 tested. This will
clear the vmcore creation status specified in $VMCORE_CREATION_STATUS,
and as a result, a notification of vmcore creation test will be
outputted.
To test kdump, there is an entry for doing that by "kdumpctl test". It
will generate a timestamp string as the ID of the current test, along
with a "pending" status in $VMCORE_CREATION_STATUS, then a real crash &
dump process will be triggered.
After system reboot back to normal, a vmcore creation check will start at
"kdumpctl (re)start/status", and will report the results as
success/fail/manual status to users.
To achieve that, program will first check the status in $VMCORE_CREATION_STATUS.
If "pending" status if found, which means the test result is
undetermined and need a retrive from remote/local dump folder. Then if test
id is found in the dump folder and vmcore is complete, then "pending"
would be overwritten by "success", which indicates a successful kdump
test. If test id is found in the dump folder but vmcore is incomplete,
then it is a "fail" kdump test. If no test id is found, then it is a "manual"
status, which indicates users should check the test results manually.
If $VMCORE_CREATION_STATUS is already success/fail/manual status, it indicates
the test result has already been determined, so the program will not access
the remote/local dump folder again. This can limite any unnecessary
access to dump target, shorten the time consumption.
User should check for the root cause of fail/manual status when get
reports.
$VMCORE_CREATION_STATUS is used for recording the vmcore creation status of
the current env. The format is like:
<status> kdump_test_id=<timestamp sec>-<timestamp nanosec>
e.g:
success kdump_test_id=1729823462-938751820
Which means, there has been a successful kdump test at
$(date -d "@1729823462") timestamp for the current env. Timestamp
nanosec is only meaningful for uniquify id string.
Difference
==========
Previously there is one commit 88525ebf ("Introduce vmcore creation
notification to kdump") merged and addressing the same issue, but
implemented differently:
The prev one:
Save the $VMCORE_CREATION_STATUS to local drive during the 2nd kernel
dumping. If vmcore dumping target is different from $VMCORE_CREATION_STATUS's
drive, then the latter one need to be mounted in 2nd kernel.
This one:
Save the $VMCORE_CREATION_STATUS to local drive only in 1nd kernel, that
is, the test result is retrived after 2nd kernel dumping. So it doesn't
load or mount other drive in 2nd kernel.
The advantage:
Extra mounting in 2nd kernel will introduce higher risk of failure,
as a result, lower the success of vmcore dumping, which is
unaccepted. So keep the code for 2nd kernel as simple is preferred.
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 status
kdump: Kdump is operational
kdump: Notice: No vmcore creation test performed!
[root@localhost ~]# kdumpctl test
[root@localhost ~]# cat /var/lib/kdump/vmcore-creation.status
pending kdump_test_id=1729823462-938751820
[root@localhost ~]# kdumpctl status
kdump: Kdump is operational
kdump: Notice: Last successful vmcore creation on Fri Oct 25 02:31:02 AM UTC 2024
[root@localhost ~]# cat /var/lib/kdump/vmcore-creation.status
success kdump_test_id=1729823462-938751820
[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 Fri Oct 25 02:31:02 AM UTC 2024
Note: the notification for kdumpctl (re)start/status can be disabled by
setting VMCORE_CREATION_NOTIFICATION in /etc/sysconfig/kdump. And fadump
is NOT supported for this feature.
Signed-off-by: Tao Liu <ltao@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
2024-12-05 04:08:38 +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". Note, fadump is not supported.
|
|
|
|
|
|
|
|
|
|
If the optional parameter [--force] is provided, there will be no confirmation
|
|
|
|
|
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)
|
