我可以在生成核心转储时启动该进程吗？

Question

我有一个监视器脚本将检查指定的进程，如果它崩溃，脚本将重新启动它而不等待核心转储写入完成。这会导致坏事吗？它会影响核心转储文件还是重新启动的进程？

Answer 1

是的，你可以。流程与程序不同。由于你可以在unix中同时运行多个ls命令的实例，所以在保存核心文件时，没有什么可以阻止你重新启动同一个程序（但是一个不同的新进程）。与写入文件的正常进程的唯一区别在于，编写core的进程只是在内核模式下执行。没别了。

核心转储由在内核模式下执行的进程执行，作为之前的die任务。出于进程状态的目的，状态退出的进程在核心转储完成之前不会影响它（它只能被转储文件中的写入错误中断，或者这可能是可中断状态）

你可以遇到的唯一问题是，你尝试编写相同核心文件名时启动的下一个实例将不得不等待它结束（我认为inode仅在每次写入时被锁定）只是，而不是整个文件），你得到一堆进程死亡和编写相同的核心文件。如果核心发生在一个新的不同文件（文件在创建之前取消链接），那就不是这种情况了，但这取决于实现。可能一个漏洞应该是DOS攻击，开始高速生成核心，使核心文件的编写在非中断状态下排队很多进程。但我认为这很难实现......很可能只有你会因为编写不同核心文件的许多进程才会获得高负载才会被删除（因为下一个核心生成任务的unlink系统调用）。

Answer 2

core(5)转储非常错误，您应该修复其根本原因。这通常是一些意外和未处理signal(7)的结果（也许是一些内存损坏给出了a SIGSEGV等等;也读了undefined behavior并且是very scared的UB）

  

如果崩溃，脚本将重新启动它而不等待核心转储写入完成。

因此，除了临时措施外，您的方法存在缺陷。 BTW，在许多情况下，错误过程的virtual address space足够小，以便core在很短的时间内被抛弃。在某些情况下，转储core可能需要几分钟（想想一个大型HPC流程处理supercomputer上数百GB的数据）。

^{有传言说，在上个世纪，一些巨大的core文件花了半个小时才被扔到Cray超级计算机上。}

你真的应该修复程序以避免转储核心。

我们根本不知道什么是你的错误程序转储核心。但是如果它有一些您关心的持久状态（例如在某些数据库或某个文件中），那么您的方法是非常错误的：core转储可能发生在生成该状态的代码中，然后，如果您重新启动相同的程序，它可以重用那个错误的状态。

  

这会导致坏事吗？

总的来说是的。也许不是在你的具体情况下（但我们不知道你的程序在做什么）。

因此，您可以更好地理解为什么core会发生。通常，您将编译程序包含所有警告和调试信息（所以gcc -Wall -Wextra -g with GCC）和use gdb以分析核心转储（见this）。

你真的不应该编写转储core的程序（即使这种情况发生在我们所有人身上;但它是一个应该尽快修复的强大错误）。并且您不应该接受core转储作为您的程序的可接受行为。

core转储可以帮助开发人员修复一些严重的问题。另请阅读Unix philosophy。在社会上不可接受的考虑是正常的＆＃34;一个core dump，这绝对是一种异常的程序行为。

^{（有几种方法可以避免core转储;但这会产生一个不同的问题;您需要解释您正在编写和监控的程序类型，以及它为什么以及如何转储核心。）}