[步骤] Linux Kdump 的开启 (用于收集内核崩溃时的信息) (CentOS 7 & Rocky Linux 8 & RHEL 7 & RHEL 8 版)

步骤一:开启 Kdump

1.1 确保 crash 和 kernel-debuginfo 两个软件包已安装

# rpm -qa | grep crash || yum install crash ; rpm -qa | grep kernel-debug || yum install kernel-debug

1.2 设置内核崩溃信息的存放位置

# vim /etc/kdump.conf

修改以下内容:

......
path /var/crash
......


补充:
1) 默认的存放位置是 /var/crash
2) 把这里修改成想要存放内核崩溃信息的目录
3) 为了保险起见存放内核崩溃信息的位置最好有大于内存大小的剩余空间

1.3 重新启动 kdump 服务并设置为开机自启

# systemctl restart kdump ; systemctl enable kdump

1.4 确保 kdump 服务已经开启

# systemctl status kdump

(补充:当显示输出结果里包含 operational 或者 Active: active (exited) 时,则说明 Kdump 已经启用)

步骤二:设置收集内核崩溃信息的触发条件

2.1 当内核崩溃时自动收集内核崩溃信息

2.1.1 修改 /etc/sysctl.conf 文件
# vim /etc/sysctl.conf

添加以下内容:

......
kernel.hung_task_panic=1
2.1.2 让修改的 /etc/sysctl.conf 文件生效
# sysctl -p /etc/sysctl.conf
2.1.3 当内核崩溃时,系统会自动收集内核崩溃信息并重启

(步骤略)


注意:
1) 只有 task hang 住,或者处理器线程 soft lock 时才会自动产生 dump
2) 此过程系统会自动重启

2.2 当内核崩溃时使用魔术键收集内核崩溃信息

2.2.1 修改 /etc/sysctl.conf 文件
# vim /etc/sysctl.conf

添加以下内容:

......
kernel.sysrq = 1
2.2.2 让修改的 /etc/sysctl.conf 文件生效
# sysctl -p /etc/sysctl.conf
2.2.3 当内核崩溃时,使用魔术键收集内核崩溃信息并让系统自动重启

同时先后按下以下三个按键:

ALT + PRINTSCREEN + C


注意:
1) 此过程会让系统自动重启
2) 只是系统死机并不代表有 kernel panic

2.3 当内核崩溃时使用硬件发送 NMI 收集内核崩溃信息

2.3.1 修改 /etc/sysctl.conf 文件
# vim /etc/sysctl.conf

添加以下内容:

......
kernel.unknown_nmi_panic = 1
kernel.panic_on_unrecovered_nmi = 1
kernel.panic_on_io_nmi = 1
2.3.2 让修改的 /etc/sysctl.conf 文件生效
# sysctl -p /etc/sysctl.conf
2.3.3 当内核崩溃时,联系硬件技术支持使用硬件发送 NMI 收集内核崩溃信息

(步骤略)

步骤三:手动触发内核崩溃测试 Kdmup

# echo c > /proc/sysrq-trigger

(注意:此操作会造成系统重启)

参考文献:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/system_design_guide/installing-and-configuring-kdump_system-design-guide
https://access.redhat.com/solutions/916043
https://access.redhat.com/solutions/3698411
https://access.redhat.com/solutions/6038
https://access.redhat.com/solutions/23069

[步骤] Linux journal 日志的永久存储

正文:

步骤一:理解 journal 日志存储机制

默认情况下,journal 的日志存储在 /run/log/journal,而 /run 目录只是一个临时目录。

将 Storage 参数设置为 persistent 后,journal 的日志将存储在 /var/log/journal,/var/log 则是一个永久的目录。

步骤二:将 journal 日志设置为永久存储

2.1 修改 /etc/systemd/journald.conf 文件

# vi /etc/systemd/journald.conf

将部分内容修改如下:

[Journal]
......
Storage=persistent
......

2.2 重启 systemd-journald 服务

# systemctl restart systemd-journald.service

参考文献:

https://linuxconfig.org/introduction-to-the-systemd-journal

[排错] Linux 解决日志里报错 “kernel: [829455.595333][ C10] critical target error, dev sda, sector 104056241 op 0x3:(DISCARD) ……”

报错代码:

kernel: [829455.595333][ C10] critical target error, dev sda, sector 104056241 op 0x3:(DISCARD) ......

分析:

如果是在 VMware 上运行的虚拟机在日志里出现 critical target error 此类报错,尤其是涉及到 DISCARD 操作的错误,通常是由 VMware 进行硬盘垃圾空间回收或者进行硬盘优化造成的。

解决方法:

VMware 的控制平台上,检查宿主机的硬盘是否正常。若不正常则修复或者更换硬盘。

[步骤] SLES supportconfig 命令收集选项的设置

步骤一:supportconfig 的作用理解

supportconfig 是一个 SLES 系统搜集系统整体情况的命令,我们可以选择搜集哪些信息

步骤二:supportconfig 命令收集选项的设置

2.1 创建 /etc/supportconfig.conf 文件

# supportconfig -C

2.2 让 supportconfig 命令不搜集某些信息

# sed -i 's\OPTION_AUDIT=1\OPTION_AUDIT=0\g' /etc/supportconfig.conf

(补充:这里使 supportconfig 命令不搜集 audit 日志为例)

Several situations of Linux automatically reboot without reboot logs in the /var/log/messages

Situation One

This Linux server is a virtual server. If we reboot it though its virtual software, there is no relevant logs in the /var/log/messages.

Situation Two

This Linux server is a member of a pacemaker cluster. If the pacemaker cluster software fences this server for protecting the whole cluster, there is no relate logs in the /var/log/messages.

Situation Three

This Linux server has critical problems in its system or hardware. Core panic of Linux and hardware problem both can reboot the system automatically without any reboot logs in the /var/log/messages.