内核恐慌日志在哪里？

Question

内核恐慌日志在哪里？

kernellog

39

我在使用Handbrake/ffmpeg时遇到了问题。大约5分钟转码后，电脑就会死机。我相当确定这是内核恐慌，因为大写锁定键开始闪烁。

关于该问题有一些逻辑上的疑问和一些关于具体错误的问题，但我真正想知道的是：在一切崩溃之前发生了什么事情？！

我已经检查了/var/log/kern.log文件，在那个时间段我只看到自己插入了一张DVD，然后几分钟后系统启动。没有错误，也没有恐慌通知。

有没有办法强制记录恐慌事件？我相当确定我可以重现这个问题（最近每次尝试都发生），所以虽然我更希望它“正常工作”，但如果这意味着我能找到恐慌的原因，我愿意重新启动几次。

- Oli

转码时是否收到任何特定的消息？这可能对找出解决方案有所帮助 ;) - Rinzwind

@Rinzwind 不对。什么都没显示出来，就卡住了。 - Oli

很可能是过热问题。转码会使CPU负荷加大，如果散热不够好，CPU就会进入紧急关机状态。例如，当CPU散热器上的导热膏干燥时，我曾经见过这种情况发生。在BIOS中设置超频时也会出现这种情况。在系统死机之前，尝试使用xsensors来监控CPU温度。 - Neil Mayhew

4个回答

26

所有在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。

- Bruno Pereira

2删除了那个"-"，重新启动了，检查了/var/log/syslog | grep panic。但是没有起作用。我有什么遗漏吗？ - AAI

最近的内核有什么变化吗？我有一个规则，规定kern.* /var/log/kern.log，但似乎紧急消息没有这个kern.xxxx标签，因此无法捕获。让我困扰的是，即使在*.*文件中也找不到它们。 - Sandeep

这个答案实际上是不完整的，它应该包含更多关于崩溃转储的信息。如果服务器因不同原因崩溃，就不会有日志记录，而唯一捕获发生情况的方法就是使用崩溃转储，可以保存在本地文件系统或远程位置（通常是NFS）。 - Bruno Pereira

7

串口

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

优点：

- 一次简单的设置（如果你有硬件） - 可靠性高，因为数据传输仅依赖于简单的线缆和内核API，不太可能受到恐慌的影响，而TCP/IP子系统则容易受到影响。

缺点：

- 大多数现代笔记本电脑不再具备串口（暴露？）以节省空间。但是台式机和虚拟机仍然支持串口。 - 您还需要另一台具备串口的计算机来接收数据，但这对于基本上所有嵌入式开发板（如树莓派）都是必需的。 - 受物理层串行电缆长度限制，不像TCP/IP网络那样无限制。但是可以通过在远程计算机的串口上插入一个将串口和TCP/IP转换的设备来解决这个问题。

串口的外观如下：

树莓派上的GPIO接口可以连接到外部设备，下面是它的外观（另一侧连接着笔记本电脑的USB接口）：

这种用法的更充分的例子可以在这里看到。

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

screen /dev/ttyS0 115200

这实际上给你提供了一个shell。

然后在主机上启动会导致恐慌的操作。

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

其他方法

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

- 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，谁还需要恐慌呢？如果你是那种极客，可以看看以下内容：

- QEMU或其他虚拟机：https://stackoverflow.com/a/42316607/895245 - JTAG

只要你有完整的可见性（和足够的时间），每个问题都会迎刃而解。

- Ciro Santilli OurBigBook.com

我不认为这对于启动时的内核恐慌有用，对吗？ - NH.

1@NH。除非是非常早期的引导，否则它应该能正常工作。我不确定确切的时间点是否100%准确。还请查看earlyprintk/earlycon命令行参数。 - Ciro Santilli OurBigBook.com

0

在桌面发行版上，内核恐慌消息不会输出，而是会在控制台中显示。您可以执行“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。

- ziqi tan

- Caesium · Accepted Answer

如果真的是内核恐慌，那么它不会通过正常方法写入日志。由于内核此时已经崩溃，写入文件系统是一项风险操作 - 内核的可信度已经很低，因此写入日志可能会在引导加载程序上产生随机垃圾！

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

Ubuntu Wiki上有一个CrashdumpRecipe可能会有用 - 尽管看起来有点过时，但我认为应该没有太大变化。