排查Azure 中的Linux 内核故障- Virtual Machines

如何识别内核崩溃？

使用 Azure 门户在启动诊断边栏选项卡、串行控制台边栏选项卡或 AZ CLI 中查看 VM 的串行控制台日志输出，以标识特定的内核死机字符串。
内核崩溃类似于下面的输出，将显示在串行控制台日志的末尾：
Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
[  300.206297] Kernel panic - xxxxxxxx
[  300.207216] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.xxx.x86_64 #1
一些最常见的内核死机事件：
Reason
内核 BUG 位于 <pathname/filename>：<line number>！
此格式是失败的 BUG 检查 (的标准，它与 ASSERT 类似，但逻辑) 反转。 文件名和行号将指示哪个 BUG 检查失败。
内核崩溃 - 未同步：软锁：挂起任务
软锁定检测器发现了一个 CPU，该 CPU 未在软锁定阈值内计划监视程序任务。
内核崩溃 - 未同步：监视程序检测到 cpu 0 上的硬 LOCKUP
硬锁定检测器发现，在硬锁定阈值内未收到任何 hrtimer 中断的 CPU。
内核崩溃 - 未同步：hung_task：阻止的任务
挂起的任务监视器检测到至少一个处于不可中断状态的任务超过阻止的任务超时值。
内核崩溃 - 未同步：内存不足。 已选择panic_on_oom
系统内存不足和交换，并被迫开始终止进程以释放内存 (不是默认行为) 。
内核崩溃 - 未同步：内存不足，没有可终止进程...
系统内存和交换已用尽，并且一直在终止进程以释放内存，但已用完要终止的进程。
内核崩溃 - 未同步：发生 NMI，有关详细信息，请参阅集成管理日志。
监视器截获了 NMI (不可掩码的中断) 。
内核崩溃 - 未同步：NMI IOCK 错误：未继续
系统从硬件收到 IO 检查 NMI， (不是内存奇偶校验错误) ，并且kernel.panic_on_io_nmi (默认) 设置。
内核崩溃 - 未同步：NMI：不继续
系统) 收到 NMI (硬件或内存奇偶校验错误，kernel.panic_on_unrecovered_nmi设置为 (非默认) 。
内核崩溃 - 未同步：nmi 监视器
系统收到了 NMI，kernel.panic_on_timeout或kernel.panic_on_oops (不是默认值) 设置的。
内核崩溃 - 未同步：致命计算机检查
已针对严重情况引发计算机检查异常事件。
内核崩溃 - 未同步：试图终止 init！
init 进程是启动的第一个进程，不应退出。
方案 1：启动时发生内核崩溃
启动时出现内核崩溃会阻止 VM 完成操作系统启动过程。 每次启动虚拟机时都会发生这种情况，并且不允许登录。
此类事件通常相关但不限于：
最近的内核升级。
最近的内核降级。
内核模块更改。
操作系统配置更改 (GRUB、sysctl 和 SELinux) 。
SELinux 问题。
缺少重要文件和目录。
缺少重要的系统核心库和包。
文件权限错误。
缺少分区。
方案 1 的解决方案
为了处理此类内核崩溃，可以使用以下方法：
方法 1：使用 Azure 串行控制台
使用 Azure 串行控制台中断启动过程，并选择以前的内核版本（如果可用）。 这样，VM 将能够再次启动，然后可以使用以下方法之一来修复非启动内核的特定问题：
重新安装或重新生成缺少的 initramfs。
重新安装有问题的内核。
查看已加载或缺少的内核模块。
查看分区。
方法 2：使用救援 VM 进行脱机修复
如果 Azure 串行控制台不可用或以前的内核不可用，则需要一个救援/修复 VM 来执行脱机修复。
使用 “修复 VM” 命令 创建附加了目标 VM OS 磁盘副本的修复 VM。 然后使用 chroot 装载修复 VM 中 OS 文件系统的副本。 之后，请尝试以下方法来修复内核问题：
重新安装或重新生成缺少的 initramfs。
重新安装有问题的内核。
查看已加载或缺少的内核模块。
查看分区。
恢复缺少的文件。
恢复缺少的重要系统核心库和包。
方案 2：运行时内核崩溃
操作系统启动过程完成后，通常会在不可预知的时间触发这种内核崩溃，并导致 VM 停止响应，阻止其登录。 它通常相关但不限于：
最近的内核升级。
最近的内核降级。
内核模块更改。
操作系统配置更改 (GRUB、sysctl 和 SELinux) 。
SELinux 问题。
应用程序工作负载更改。
应用程序开发更改或 bug。
可能的内核 bug。
与性能相关的问题。
方案 2 的解决方案
为了处理此类内核崩溃，可以使用以下方法：
查看资源使用情况和整体系统性能。 内核崩溃可能与资源短缺有关，这可能导致 VM 大小调整。
如果可能，请安装相应 Linux 分发存储库中提供的最新更新。 内核崩溃可能与内核或其他软件中的已知 bug 有关。
内核崩溃可能与最近的内核更改有关，在这种情况下，建议通过以前的内核版本启动，如 方案 1 的解决方法中所述。
如果上述选项不适用，可能需要配置 kdump 并生成核心转储，以便与支持人员共享，以便进一步分析。
更具体的内核崩溃方案
具有特定故障排除/恢复说明的常见内核崩溃方案：
主机节点升级后，基于 3.10 的内核上的 Azure Linux VM 出现死机
本文讨论在 Azure 中升级主机节点后运行基于 3.10 的内核的 Azure Linux VM 发生故障时出现的问题。
如何从与内核相关的启动问题中恢复 Azure Linux 虚拟机
本文提供了 Linux 虚拟机 (VM) 应用内核更改后无法重启的问题的解决方案。
联系我们寻求帮助
如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 还可以向 Azure 社区支持提交产品反馈。