【问题标题】:Delayed kernel panic in LinuxLinux 中延迟的内核恐慌
【发布时间】:2019-02-27 18:26:21
【问题描述】:

对于我们的测试,我们需要通过 SSH 在远程服务器 (VM) 上触发内核崩溃:

ssh server "echo c > /proc/sysrq-trigger"

问题在于,在大多数情况下,SSH 会话会卡住,因为内核崩溃发生在连接断开之前。有一个通用的连接超时,但这还不够好。

有没有办法延缓恐慌?

我们尝试将以下内容放在服务器上的文件中:

# - panic.sh -

#/bin/bash
sleep 5
echo c > /proc/sysrq-trigger

然后执行它:

ssh server "nohup panic.sh &"

但这没有帮助。 SSH 会话一直等到睡眠结束。

【问题讨论】:

    标签: linux bash remote-access panic


    【解决方案1】:

    发生这种情况是因为您的脚本保持所有管道打开,所以ssh 必须等待,看看您是否会写更多。

    如果你全部关闭它们,ssh 知道它不会再收到任何输出并将退出:

    $ time ssh localhost 'sleep 5 < /dev/null > log 2>&1 &'
    real    0m0.171s
    user    0m0.013s
    sys     0m0.003s
    

    您也可以在睡眠前使用exec 命令在脚本中执行此操作:

    exec < /dev/null > log 2>&1
    

    【讨论】:

    • 只是想知道,ssh -T server "echo c &gt; /proc/sysrq-trigger" 就足够了吗?没有伪终端是否意味着没有返回本地主机的管道?
    • 已经没有 pty,这就是为什么你得到管道而不是终端的原因。不过,从技术上讲,您可以做相反的事情:请求一个 pty 使 nohup 使用 ssh -t localhost 'nohup sleep 5 &amp;' 重定向远离它。这虽然不那么明确而且更嘈杂
    • 非常酷,谢谢!我也玩过重定向,但找不到正确的组合。在脚本中使用exec &lt; /dev/null &gt; log 2&gt;&amp;1
    猜你喜欢
    • 1970-01-01
    • 2013-12-12
    • 1970-01-01
    • 2021-01-13
    • 1970-01-01
    • 2020-01-28
    • 2013-06-15
    • 1970-01-01
    • 2012-02-08
    相关资源
    最近更新 更多