用户级程序应该捕获哪些“致命”的信号?

首先, 我知道过去也有类似的问题 。

但这个问题没有得到妥善的回答。 相反,它转而build议做些什么来捕捉信号

所以只是为了澄清:我已经做了任何需要处理的信号。 我有一个应用程序,通过pipe道监视主进程的守护进程。 如果一个主进程崩溃(如分段错误),它有一个信号处理程序,将所有需要的信息写入pipe道并中止。

目标是当应用程序出现问题 ,尽可能多地获取信息,而不用“正常”操作,如SIGHUP,SIGUSR1等。

所以我的问题是: 我应该捕捉哪些信号? 我的意思是没有我抓到他们的信号会导致应用程序中止。

到目前为止我已经提出了以下列表:

  • SIGINT(^ C,用户发起,但仍然很好知道)
  • SIGTERM(从shell或AFAIK中kill <pid>可能是OutOfMemory的结果)
  • SIGSEGV
  • SIGILL
  • SIGFPE
  • SIGBUS
  • SIGQUIT

有人知道我错过了什么吗? kill -l有很多… 🙂

我在看我的高级编程unix环境(Stevens)的副本。 根据信号部分的表格,如果你没有捕获到信号,下面的POSIX信号默认会终止这个过程。 监测你不使用的所有这些并不是不合理的:

  • SIGABRT
  • SIGALRM
  • SIGFPE
  • SIGHUP
  • SIGILL
  • SIGINT
  • SIGKILL
  • SIGPIPE
  • SIGQUIT
  • SIGSEGV
  • SIGTERM
  • SIGUSR1
  • SIGUSR2

除了SIGKILL,你可以捕获所有这些,但希望SIGKILL不会经常为你而来。

请注意,您的信号手册页( man 7 signal )应该为您的系统提供正确的列表 – 这是POSIX列表,并且可能会因您的体系结构而有所不同。

你不应该捕捉信号,并将代码写入管道。 这是不必要的,不是安全的。

让我引用你所连接问题的一个答案,指出为什么它不是安全的: “什么让你觉得SEGV还没有破坏你的程序内存?

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

可以使用WIFSIGNALED()来检查waitpid系统调用的返回代码,以确定进程是否正常终止或通过信号终止, WTERMSIG()将返回信号编号。

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

这取决于:无论你喜欢什么样的信号,如果这有助于通知用户一些不好的事情发生。 但是SIGKILL和SIGSTOP不能被捕获。