推荐的信号捕捉？答案

【问题标题】：Recommended signals to catch?推荐的信号捕捉？
【发布时间】：2011-03-14 19:41:30
【问题描述】：

目前，我捕获了 SIGSEGV，给自己发送了一封电子邮件，然后 abort() 以便我可以获取核心文件并调试我的程序。（如果我没有捕捉到，我就不可能不知道我的特定程序出现了段错误。我的程序运行在与我自己的服务器不同的服务器上。）

是否有任何其他信号我应该捕获以进行调试或出于我应该知道的原因？

【问题讨论】：

标签： c linux posix

【解决方案1】：

是什么让您认为 SEGV 没有已经严重损坏您的程序内存，以至于发送电子邮件的尝试不会失败？

您应该遵循责任分工的做法，并从一个完全不同的计划中监控您的计划。

只需有一个（非常简单，因此失败的可能性要小得多）程序来检查以确保您的主程序仍在运行，如果没有，则向您发送该电子邮件。您甚至可以进行纵深防御并运行两个检查器，这两个检查器都检查主程序并相互检查。

如果你像我一样偏执，你甚至可以在不同的机器上运行它们:-)

【讨论】：

好的，因为使用 signal.h 不能保证工作，这个怎么样：1.) 从我的程序中删除 signal.h 2.) 将 setrlimit 作为我程序的第一行，这样我就可以获取核心 3.) 使用由 cronjob 执行的 shell 脚本来检查核心文件，如果有则给我发送电子邮件
我认为，在 Linux 上，SIGSEGV 会自动为您提供核心转储，除非有人采取特定措施阻止它发生。如果是这种情况，下次程序启动时，它可以检查其工作目录中的内核，然后发送电子邮件。我认为这是大多数崩溃报告者在 OS X 上工作的方式。
@JeremyP：SIGSEGV 转储内核，但内核在 Linux 发行版上默认禁用，因此您必须使用 setrlimit 修改软限制（假设硬限制不为零，否则您需要 root 权限） .
@Jason：好的，按照你的建议使用 setrlimit 似乎是合理的。

【解决方案2】：

好吧，如果您的程序附加到控制台，您可能希望捕获 SIGINT 以转储/刷新您保留的任何缓冲区/日志。

【讨论】：

【解决方案3】：

您可能不应该捕获 SIGSEGV / SIGBUS 等。

您应该做的是编写一个包装程序，该程序将检测子进程是否从信号中退出，并识别问题，然后该进程可以执行任何所需的操作。

如果它是一个服务器进程，你可能还想在它意外失败时重新启动。

【讨论】：