☰

echo c | sudo tee /proc/sysrq-trigger 导致崩溃并且系统无法重新启动

tag-icon • tag-icon kernel
echo c | sudo tee /proc/sysrq-trigger 导致崩溃并且系统无法重新启动

我正在学习 Ubuntu 的服务器指南，但无法解决这个问题。

我遵循以下步骤：

sudo -s
[sudo] password for ubuntu:
# echo c > /proc/sysrq-trigger
[ 31.659002] SysRq : Trigger a crash
[ 31.659749] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 31.662668] IP: [<ffffffff8139f166>] sysrq_handle_crash+0x16/0x20
[ 31.662668] PGD 3bfb9067 PUD 368a7067 PMD 0
[ 31.662668] Oops: 0002 [#1] SMP
[ 31.662668] CPU 1

我sudo sysctl -w kernel.sysrq=1也是

但屏幕保持冻结状态，系统无法重新启动。我可以手动重新启动系统，但重新启动后ls /var/crash没有任何反应。

我怎样才能解决这个问题？

答案1

这就是它应该做的事。

服务器可能需要很长时间才能转储内存，并且根据主机的不同，它们可能会“捕获”内存并对其进行一些奇怪的操作。我的建议是“别再捣乱了”。

该命令会触发内核崩溃。仅此而已。所有这些额外的东西都是可配置的，而且并不真正可靠。您的托管服务提供商可能会发现它（特别是如果它是像 Amazon EC2 这样的，他们会构建自己的内核和基础映像）。

捕获生产级内核崩溃的最佳方法是使用某种类型的主机监控。我使用并推荐 Nagios。当服务器在生产环境中停止响应时，重新启动永远都不是答案。围绕这种类型的内核崩溃处理进行测试和构建协议只会导致您以最惊人的方式失败。

如果您需要系统日志或崩溃日志，请查看使用系统日志的远程功能。

简而言之，从托管 101 开始，如果您无法承受停机时间，请不要依赖自动重启等廉价技巧，设置适当的主机监控解决方案和集群。

答案2

我执行了同样的命令，结果导致内核崩溃。因此我决定用 Google 搜索一下，并找到了一些有趣的信息。

当我们执行此命令时会导致内核测试崩溃

echo c | sudo tee /proc/sysrq-trigger

根据Ubuntu 文档

如果一切正常，应该会有一些延迟（取决于内存大小）。然后系统重新启动进入正常模式。通常 apport 会启动并询问是否报告问题。或者，可以在 /var/crash 下找到报告文件，并将其放在其他地方，或者通过调用以下命令再次解压：

#> apport-unpack <report file> <target directory>

这完全取决于内存大小。我会搜索一下 4GB 内存的电脑需要多长时间。我手动重启了系统，但不到 2 分钟。希望这对你有帮助。

相关内容