用户级程序应该捕获哪些"致命"信号？

Question

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

但这个问题没有得到妥善回答.相反,它转而建议如何捕捉信号.

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

目标是在应用程序发生不良事件时尽可能多地获取信息,而不用处理"正常"操作,例如SIGHUP,SIGUSR1等.

所以我的问题是:我应该抓住哪些信号？ 我的意思是说,如果没有我捕获它们的信号会导致应用程序中止.

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

• SIGINT(^ C,用户启动,但仍然很好知道)
• SIGTERM(kill <pid>来自shell或AFAIK,可以是OutOfMemory的结果)
• SIGSEGV
• SIGILL
• SIGFPE
• SIGBUS
• SIGQUIT

有人知道我是否错过了什么？kill -l有很多...... :)

Answer 1

我正在查看我的高级编程副本unix环境(Stevens).根据有关信号的部分中的表格,如果您没有捕获它们,则以下POSIX信号将默认终止该过程.监控您不使用的所有这些并不是不合理的:

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

除了SIGKILL,你可以捕获所有这些,但希望SIGKILL不会经常出现给你.

请注意,您的信号手册页(man 7 signal)应该为您提供适合您系统的列表 - 这是POSIX列表,并且可能因您的体系结构而异.

Answer 2

您不应该捕获信号并将代码写入管道.这既不必要也不安全.

让我引用你所链接的问题的答案,指出为什么它不是故障保护:"是什么让你觉得SEGV还没有破坏你的程序记忆"

现在你可能想知道如何做得更好,为什么我说它是"不必要的".

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

这是故障安全的,它不需要处理程序或管道.此外,您无需担心要捕获的内容,因为它会报告终止您的过程的每个信号.