为Proxmox启动kdump
为Proxmox启动Kdump捕获异常
本文将记录如何在Proxmox系统中安装配置Kdump,Kdump可以在系统遇到故障时及时捕获异常,是系统排障的最佳选择之一,建议所有人为自己的Proxmox系统安装配置以备不时之需。
当然如果有可能,我更希望你永远也用不上这个。
测试环境
硬件环境
AMD 7950X
TUF B650M Plus
128G DDR5
256+1T
软件环境
Proxmox 8.1.3
安装软件
apt update
apt install kdump -y
配置软件
编辑配置文件
编辑Kdump的配置文件,如果自行选择使用nano或者vim编辑,个人推荐nano好用一点。
nano /etc/default/grub.d/kdump-tools.cfg
如果我们的版本一样或者差不多的话,里面只有一行配置,你的配置应该和这个类似,但是后面的一些参数可能你的会和下面的有所不同。
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=512M-2G:64M,2G-100G:128M,100G-:2G"
配置解释
crashkernel:
- 这个参数用于为 kdump 保留特定数量的内存。当系统崩溃时,kdump 会使用这部分内存启动一个崭新的内核来捕获内存转储。
- 根据系统总内存的不同,保留不同大小的内存块。格式为:<内存范围>:<保留内存大小>,多个范围用逗号分隔。
所以你可以粗略的将冒号作为分隔线,比如下面的配置可以说明为。
- 512M-2G:64M
- 当系统内存为512M 到 2G时,分配64M给Kdump用于处理崩溃后的系统。
- 2G-100G:128M
- 当系统内存为2G 到 100G时,分配128M给Kdump用于处理崩溃后的系统。
- 100G-:2G
- 当系统的内存大于100G时,分配2G给Kdump用于处理崩溃后的系统。
检查Kdump服务
检查Kdump是否已经启动。
systemctl status kdump-tools
root@pve:~# systemctl status kdump-tools
● kdump-tools.service - Kernel crash dump capture service
Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; preset: enabled)
Active: active (exited) since Tue 2024-06-25 18:21:35 CST; 17min ago
Process: 1292 ExecStart=/etc/init.d/kdump-tools start (code=exited, status=0/SUCCESS)
Main PID: 1292 (code=exited, status=0/SUCCESS)
CPU: 354ms
如果你得到的结果和上面类似,是active
,则代表Kdump已经正常启动。
如果你不确定这个服务是否开机启动,请使用
systemctl enable kdump-tools
保存文件,输入update-grub
命令来让配置生效。
reboot
,重启系统。
验证生效
pve重启完成后,可以在journalctl查看kdump启动的日志,如果你的启动出现了明显失败的字样,比如fail
,bye
等字样,则为配置有误,需要检查配置是否正确。
root@pve:~# journalctl -r -u kdump-tools
Jun 25 18:21:35 pve systemd[1]: Finished kdump-tools.service - Kernel crash dump capture service.
Jun 25 18:21:35 pve kdump-tools[1423]: loaded kdump kernel
Jun 25 18:21:35 pve kdump-tools[1420]: /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-6.5.11-4-pve root=/dev/mapper/pve-root ro quiet reset_devices sy>
Jun 25 18:21:35 pve kdump-tools[1330]: loaded kdump kernel.
Jun 25 18:21:35 pve kdump-tools[1330]: Creating symlink /var/lib/kdump/initrd.img.
Jun 25 18:21:35 pve kdump-tools[1330]: Creating symlink /var/lib/kdump/vmlinuz.
Jun 25 18:21:35 pve kdump-tools[1292]: Starting kdump-tools:
Jun 25 18:21:35 pve systemd[1]: Starting kdump-tools.service - Kernel crash dump capture service...
崩溃转储验证
请注意,本操作会直接崩掉系统(不会造成硬件损害),请勿在生产环境进行。
请注意,本操作会直接崩掉系统(不会造成硬件损害),请勿在生产环境进行。
请注意,本操作会直接崩掉系统(不会造成硬件损害),请勿在生产环境进行。
注意观察链接系统的屏幕,在命令行输入
echo c > /proc/sysrq-trigger
输入后系统光标卡死,键盘灯熄灭,较短
一些时间后系统重启。
如果此时你的系统长时间卡死没有重启
,可能代表你的Kdump配置有误,需要去检查配置文件,网上有一些说法,让你去改的文件和我上面指出的文件不一致,注意甄别。
重启启动完成后,可以使用journalctl看到kdump的工作日志,同时也可以发现journalctl并没有记录下我们需要的日志
,这就是使用kdump的意义
,详情见下方的Jun 25 18:51:11 pve kdump-tools[508]:
开始。
Jun 25 18:51:11 pve systemd[1]: Starting kdump-tools-dump.service - Kernel crash dump capture service...
Jun 25 18:51:11 pve systemd[1]: open-iscsi.service - Login to default iSCSI targets was skipped because no trigger condition checks were met.
Jun 25 18:51:11 pve systemd[1]: Reached target remote-fs-pre.target - Preparation for Remote File Systems.
Jun 25 18:51:11 pve systemd[1]: Finished blk-availability.service - Availability of block devices.
Jun 25 18:51:11 pve kdump-tools[508]: Starting kdump-tools:
Jun 25 18:51:11 pve kdump-tools[512]: running makedumpfile -F -c -d 31 /proc/vmcore | compress > /var/crash/202406251851/dump-incomplete.
Jun 25 18:51:11 pve kernel: vmbr0: port 1(eno1) entered disabled state
Jun 25 18:51:18 pve kdump-tools[528]: [1.6K blob data]
Jun 25 18:51:18 pve kdump-tools[528]: The dumpfile is saved to STDOUT.
Jun 25 18:51:18 pve kdump-tools[528]: makedumpfile Completed.
Jun 25 18:51:18 pve kdump-tools[512]: kdump-tools: saved vmcore in /var/crash/202406251851.
Jun 25 18:51:18 pve kdump-tools[532]: saved vmcore in /var/crash/202406251851
Jun 25 18:51:18 pve kdump-tools[512]: running makedumpfile --dump-dmesg /proc/vmcore /var/crash/202406251851/dmesg.202406251851.
Jun 25 18:51:18 pve kdump-tools[534]: The dmesg log is saved to /var/crash/202406251851/dmesg.202406251851.
Jun 25 18:51:18 pve kdump-tools[534]: makedumpfile Completed.
Jun 25 18:51:18 pve kdump-tools[512]: kdump-tools: saved dmesg content in /var/crash/202406251851.
Jun 25 18:51:18 pve kdump-tools[535]: saved dmesg content in /var/crash/202406251851
Jun 25 18:51:18 pve kdump-tools[537]: Tue, 25 Jun 2024 18:51:18 +0800
-- Boot 3d384452b3d744db8ad7b48b3629a29e --
Jun 25 18:51:38 pve kernel: Linux version 6.5.11-4-pve (fgruenbichler@yuna) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEM>
进入崩溃日志的储存目录,可以看到产生了今日的崩溃记录202406251851
,进入文件夹后可以看到包含两个文件。
注意,其实正常情况下,应该会生成
vmcore
,至于为什么没有生成的原因是因为Proxmox的这个核心似乎不受支持,如果你使用了市面上较为常用的系统安装Proxmox,则会产生vmcore
文件,你可以使用crash
工具读取该文件,这个文件中包含了崩溃时系统的很多状态,可以更细致的分析问题原因。你可以使用uname -r
看到自己的系统信息,如果你不是使用Proxmox官方的安装工具安装而在其他Linux发行版中安装,vmcore将对你可用。
cd /var/crash
root@pve:/var/crash# ls
202406251851 kdump_lock kexec_cmd
root@pve:/var/crash/202406251851# ls
dmesg.202406251851 dump.202406251851
使用nano
查看dmesg.202406251851
文件翻页到最下方,可以发现问题原因是我们之前输入的指令,注意1777.129960
的那一行。
[ 17.616160] [ T238] vmbr0: port 1(eno1) entered forwarding state
[ 17.942498] [ T1740] kvm[1740]: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set
[ 1777.129960] [ T5956] sysrq: Trigger a crash
[ 1777.129977] [ T5956] Kernel panic - not syncing: sysrq triggered crash
[ 1777.129987] [ T5956] CPU: 21 PID: 5956 Comm: bash Kdump: loaded Tainted: P O 6.5.11-4-pve #1
[ 1777.129998] [ T5956] Hardware name: ASUS System Product Name/TUF GAMING B650M-PLUS, BIOS 2613 04/12/2024
[ 1777.130013] [ T5956] Call Trace:
[ 1777.130019] [ T5956] <TASK>
[ 1777.130026] [ T5956] dump_stack_lvl+0x48/0x70
[ 1777.130036] [ T5956] dump_stack+0x10/0x20
[ 1777.130043] [ T5956] panic+0x2e8/0x360
[ 1777.130051] [ T5956] ? srso_alias_return_thunk+0x5/0x7f
[ 1777.130061] [ T5956] sysrq_handle_crash+0x1a/0x20
[ 1777.130070] [ T5956] __handle_sysrq+0xe5/0x1a0
[ 1777.130076] [ T5956] ? wp_page_reuse+0x67/0x90
...
Tips
一般情况下,如果你的pve突然出现莫名其妙的突然重启,如果确认你的主板的来源正规的话(非二手非咸鱼),大部分情况下是内存的锅,你可以在错误日志出频繁看到page
相关的错误,本条仅供参考。
总结
一般情况下,只要不是在那种特别恶劣的环境下,即使是消费级硬件,也可以有很好的稳定性,但是Kdump作为一个保底排查手段,仍然建议安装使用。
另外某些对自己系统稳定性特别有自信的选手其实可以选配这个,毕竟,我自己就有一台特别能抗的,附一张自己一台消费级设备的在线时间,中途因为吹灰关了一次机,如果不吹灰的话大约是400d+稳定。