【问题标题】:Shorting the time between process crash and shooting server in the head?缩短进程崩溃和射击服务器之间的时间?
【发布时间】:2015-07-12 22:50:48
【问题描述】:

我有一个程序会导致 linux 崩溃并使用系统函数强制重启。

现在我有一个问题,当某个进程死亡时我需要使 linux 崩溃。使用脚本启动进程,如果脚本结束重启服务器是不合适的,因为它需要一些毫秒。

另一个想法是同时产生拍摄过程并使用计数器轮询,如果计数器没有增加,则重新启动服务器将是另一个想法。

这将导致几乎立即的反应。

现在的问题是什么是一个好的时间表。我不知道 linux 的调度程序如何保证任何此类计数器的某个更新以及一个好的超时时间。

我还想听听第二个进程产生的一些替代方案。是否有可能建议 linux 在给定进程崩溃的情况下运行某个例程,或者在给定进程出现问题的情况下使用侦听器机制?

【问题讨论】:

    标签: linux multithreading


    【解决方案1】:

    超时的想法已经在内核中实现了。您可以将任何应用程序注册为软件看门狗,但您必须降低默认超时时间。看看http://linux.die.net/man/8/watchdog 了解一些想法。该应用程序还可以处理用户定义的测试。实际上,除非您尝试运行像 linux-rt 这样的内核,否则在负载较重的系统上,超时时间低于 100 毫秒可能会很危险——尤其是在检查需要轮询另一个应用程序时。

    在应用程序崩溃的情况下,如果您的 init 支持通知,您可以处理它们。例如both upstart and systemd can do that 通过监视文件(确保在正确的位置创建核心转储)。

    但无论如何,我建议重新考虑以毫秒为分辨率重新启动的想法。到时候真的需要杀掉系统,还是只需要隔离?仅同步磁盘将花费几毫秒的额外时间,您可能不想错过该步骤。您可以确保受影响的应用程序不工作(SIGABRT?)并终止所有网络(刷新 iptables,将默认设置更改为 DROP),而不是仅仅杀死主机。

    【讨论】:

    • 感谢您的提示。我需要立即隔离该服务器上的节点。此外,所有数据存储都是在考虑部分写入的情况下开发的,所以我在这方面很好。更有可能杀死中期甚至有助于恢复。
    • 我还找到了一个很好的解决方案,它使用套接字共享(辅助消息)来集中所有外部和节点间通信,我可以轮询共享内存中的一个标志,以指示整个集合的完全隔离节点并给我一些时间来杀死盒子。让行为不端的节点(遇到未明确设计和实现的故障场景)能够发送消息是最糟糕的噩梦。对于不同的数据,有适当的恢复机制,但不适用于源自这些场景的消息。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2013-07-25
    • 1970-01-01
    • 1970-01-01
    • 2017-07-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多