☰

内核崩溃日志在哪里？

tag-icon • tag-icon kernel log
内核崩溃日志在哪里？

我的 Handbrake/ffmpeg 出了问题。转码约 5 分钟后，计算机就死机了。我确信这是内核崩溃，因为 caps-lock 开始闪烁。

关于该做什么和特定的错误有一些合乎逻辑的问题，但我真正追求的是一件事情：在一切消亡之前发生了什么？！

我检查了一下/var/log/kern.log，发现我插入 DVD 几分钟后系统就启动了。没有错误，也没有警告。

有什么方法可以强制记录恐慌？我很确定我可以重现这种情况（最近我尝试的时候 100% 都会发生这种情况），所以尽管我宁愿这个“只是起作用”，但如果这意味着我可以找到恐慌的原因，我很乐意重新启动几次。

答案1

如果真的是内核崩溃，那么它不会通过正常方法写入日志。由于此时内核已经崩溃，因此写入文件系统是一项危险的操作 - 内核的大部分内容不再值得信任，因此写入日志实际上可能会在您的引导加载程序上喷涌随机垃圾！

相反，您可以将内存内容转储到交换区，然后稍后进行调试。这称为内核崩溃/核心转储。

Ubuntu Wiki 有一个崩溃转储配方这可能是有用的 - 虽然它看起来有点过时，但我认为不应该改变太多。

答案2

Ubuntu 中的所有系统日志均由rsyslog它保持其配置在/etc/rsyslog.conf和中/etc/rsyslog.d/。

有关如何配置的更多信息rsyslog以及可能的选项，请访问rsyslog.conf man page。

打开后/etc/rsyslog.d/50-default.conf你会看到其中一行包含

*.*;auth,authpriv.none -/var/log/syslog*

这意味着在这种情况下您正在寻找的文件是/var/log/syslog您可能拥有的任何大型日志。

您可以看到文件名也以 开头-，这意味着文件在写入之前会被缓存，这很好，但可能会给您留下糟糕的日志，您想要的是一旦出现问题就立即写入日志。删除破折号并重新启动或重新加载rsyslog，然后让您的计算机再次崩溃，检查/var/log/syslog。

答案3

串行端口

串行端口是计算机之间的一种简单的低级通信机制。

优点：

  • 简单设置一次（如果您有硬件）
  • 可靠，因为数据传输仅依赖于简单的线路和内核 API，与 TCP/IP 子系统相比，它受恐慌的影响较小。

缺点：

  • 为了节省空间，大多数现代笔记本电脑不再有串行端口（暴露在外？）。但台式机和虚拟机仍然有。
  • 您还需要第二台带有串行端口的计算机来接收数据，但基本上所有嵌入式开发板（例如 Raspberry Pi）都是这种情况。
  • 受物理层串行电缆长度的限制，而 TCP/IP 网络则不受限制。不过，可以通过在远程计算机的串行上插入一个在串行和 TCP/IP 之间进行转换的设备来解决此问题

串行端口如下所示：

并且可以通过 GPIO 在 RPI 上使用，它看起来是这样的（另一侧带有连接到笔记本电脑的 USB 接口）：

一个使用中的例子可以在这里看到。

然后，如果您拥有所需的硬件，请使用以下命令从第二台计算机连接到主计算机：

screen /dev/ttyS0 115200

这实际上给了你一个 shell。

然后在主机上启动发生 panic 的操作。

当发生恐慌时，恐慌转储会传输到第二台机器，您可以通过在终端上向上滚动来查看所有内容。

其他方法

还有其他方法可以克服上述硬件限制，但代价是更复杂且可靠性更低。值得注意的方法：

  • netdump：通过 TCP/IP 传输恐慌。依赖于 TCP/IP 子系统未损坏。
  • kdump：似乎是在以下位置提到的 linux-crashdump 的底层机制：https://askubuntu.com/a/104793/52975启动第二个 Linux 内核来检查崩溃的内核。可能出现什么问题？！:-)

另请参阅这个精彩的答案：https://unix.stackexchange.com/questions/60574/determining-cause-of-linux-kernel-panic

单步调试

最终，获取恐慌输出需要某些内核功能起作用，并且任何内核功能都可能因恐慌而破坏。

但是如果你可以在内核上使用 GDB，谁还需要恐慌呢？如果你真的那么硬核，看看：

一旦您拥有充分的了解（和足够的时间！）所有问题都会迎刃而解。

答案4

在桌面发行版上，内核崩溃信息不会输出，控制台会输出。你可以执行“sudo systemctl set-default multi-user.target”禁用桌面，下次重启时进入控制台，这样你就可以看到崩溃信息了。根据崩溃信息确认错误类型后，例如“softlockup”，你可以设置“kern.softlockup=1”并再次重启，kexec/kdump 就可以正常工作了。参见https://stackoverflow.com/questions/64099710/where-does-the-linux-kernel-panic-message-go/64099932#64099932

相关内容