C 其中"；致命的；用户级程序应捕获的信号？

首先

但这个问题没有得到正确的回答。相反，它转而提出了如何捕捉信号的建议

所以我想澄清一下：我已经做了所有需要做的事情来处理信号。 我有一个应用程序，它派生一个通过管道监视主进程的守护进程。 如果主进程崩溃（例如分段故障），它有一个信号处理程序，将所有需要的信息写入管道并中止

我们的目标是在应用程序发生错误时，尽可能多地获取信息，而不影响“正常”操作，如SIGHUP、SIGUSR1等

所以我的问题是：我应该捕捉哪些信号？ 我的意思是，如果不捕获它们，应用程序无论如何都会中止

到目前为止，我已经列出了以下清单：

• SIGINT（^C，用户发起，但仍然很好地了解）
• SIGTERM（

  kill

  来自shell，或者，可能是OutOfMemory的结果）
• 西格塞格夫
• 西格尔
• SIGFPE
• 西格布斯
• 西格金

---

有人知道我错过了什么吗

kill-l

有很多这样的东西…：）

视情况而定：如果有什么有用的信号可以告诉用户刚刚发生了什么不好的事情，那么你喜欢什么信号都行。但是，不能捕获SIGKILL和SIGSTOP。

您不应该捕获信号并将代码写入管道。这既不必要，也不是故障保护

让我引用你链接到的问题的答案，来指出为什么它不是故障保护：“是什么让你认为SEGV还没有损坏你的程序内存？”

现在你可能想知道如何做得更好，为什么我说这是“不必要的”

可以使用

WIFSIGNALED（）

检查

waitpid

系统调用的返回代码，以确定进程是正常终止还是通过信号终止，并且

WTERMSIG（）

将返回信号号

---

这是故障保护，不需要处理程序或管道。另外，您不必担心捕捉到什么，因为它会报告终止进程的每个信号。

我正在看我的unix环境高级编程副本（Stevens）。根据信号部分中的表格，如果您没有捕获到以下POSIX信号，则默认情况下，它们将终止进程。监控您不使用的所有这些功能并不是不合理的：

• 西格布特
• 西格尔姆
• SIGFPE
• 叹息
• 西格尔
• 信号
• 西格基尔
• 信号管
• 西格金
• 西格塞格夫
• 西格特姆
• SIGUSR1
• SIGUSR2

除了SIGKILL，你可以看到所有这些，但希望SIGKILL不会经常出现在你面前

---

请注意，您的信号手册页（

man 7 signal

）应该为您的系统提供适当的列表-这是POSIX列表，可能因您的体系结构而异。

那么您已经从信号处理程序记录了哪些信息？您希望另外记录哪些信息？例如，我获得完整的回溯并通过管道将其发送给监控守护进程，然后退出主进程。正如您链接的问题的答案所述，试图从由于接收到

SIGSEGV

而调用的信号处理程序中执行soemthing是一件相当模糊的事情。@alk我知道，这就是为什么我说我已经做了所有需要做的事情。我们可以详细讨论这一点，但这不是问题的重点，我不希望讨论再次偏离主题。这实际上取决于您编写的是什么样的程序。一些提供非常重要服务的服务器程序应该比其他程序更担心信令。细节是特定于操作系统的。“不管你喜欢什么信号，这对通知用户刚刚发生了什么不好的事情非常有用”-好吧，这就是问题的重点。哪些信号是相关的？我的意思是只有会导致应用程序中止的“致命”信号。您的应用程序不会意外中止。@alk:好的，我会将其添加到我的待办事项列表：-）同意。在标准情况下，不会向进程发送这样的“非用户定义”信号，因为它编码良好，并按预期运行。@Damon:

WIFSIGNALED（）

-有趣的是，在那个问题上我可能错过了这个。然而，对我来说，获得尽可能多的信息是非常有价值的，即使处理SIGSEGV的函数会因为堆已经损坏而崩溃。我仍然有机会，它没有你想象的那么坏，我会得到有价值的信息出来。只要等待孩子结束，我就不会得到回溯。@kliteyn:是以故障保护的方式自动生成的。Core已经是

SIGSEGV

、

SIGILL

、

SIGABRT

和

SIGFPE

的默认配置。如果这还不够，您还可以相应地设置任何其他信号的处理。@Damon:这是一个可移植的应用程序，也可以在禁止转储核心文件的嵌入式系统上运行。因此，无论我在失败期间收集到什么信息，都是我所拥有的一切。一旦应用程序退出-就是这样，这一刻就过去了。谢谢，这正是我想要的：-）