Question

由于以下三个原因之一，进程被终止：它们已达到执行结束（正常情况），它们包含未捕获的异常（同步崩溃）或它们已经收到一些信号，表明它们没有处理（异步崩溃）。在程序的设计中，我们可以检测至少检测其中每一种的方式（例如catch语句，信号处理程序等）。

假设我想设计一个程序来监视Linux中另一个程序的执行。我可以通过注意到其PID从/proc中消失来轻松判断程序是否终止，但是我不知道为什么。有没有一种方法可以观察目标程序以确定终止原因？

Answer 1

主要限制是您需要的详细信息数量。在操作系统级别，您基本上只能算出杀死该进程的退出代码或信号。

根据您的限制，有多种选择：

wait-允许快速通知（阻止呼叫或发出信号），但仅适用于直子。
ptrace，直接（比较棘手）或通过strace命令；它有局限性，例如单个进程一次只能跟踪一个进程，但是它允许指定一个要监视的syscall列表，因此它不需要像strace的默认调用那样慢。
BSD流程记帐。通常需要root特权才能访问，并且绝对需要他们启用它（它是全局的）。运行后，您可以有效地观看文件，该文件可以通过编程方式（acct结构中的ac_exitcode字段）或通过lastcomm命令（包括退出代码/信号）为每个完成过程增加一个条目（ cf SendMessage）。

Answer 2

由于以下三个原因之一，进程被终止：（a），它们已经达到执行的结尾（正常情况下），（b），它们包含未捕获的异常（同步崩溃）或（c），他们已经收到一些自己没有处理的信号（异步崩溃）。

我不确定（a）是什么意思-即使程序从其main()函数返回，它仍然通过显式调用_exit(2)（或exit_group(2)）系统调用（首先从称为main()的C运行时代码开始）。如果不调用_exit()，它将崩溃。

此外，我看不出（b）和（c）有什么区别：在两种情况下它们都会收到信号-他们可以捕获，阻止或忽略（SIGKILL或SIGSTOP除外，但strace(1)不会终止该过程）。

假设我想设计一个程序来监视Linux中另一个程序的执行。

然后，您应该模仿gdb(1)或ptrace(PTRACE_ATTACH)在做什么：使用strace -e trace=none -p PID strace -e trace=exit,exit_group -p PID等。例如，这将仅监视进程的退出，而不监视其所有系统调用：

PTRACE_O_TRACEEXIT

ptrace(2)的{{1}}选项很有趣：

The tracee is stopped early during process exit, when registers are still available, allowing the tracer to see where the exit occurred, whereas the normal exit notification is done after the process is finished exiting.

Linux还具有proc connector netlink接口，该接口可让您监视进程而不会以任何方式停止或影响它们。但是，它仅作为root用户工作。使用proc连接器接口的示例程序为forkstat(1)：

forkstat -e exit   # will show all exiting processes
stdbuf -oL forkstat -e exit | grep -m1 PID  # will only show when PID exits

如何检测为什么进程在Linux中以编程方式终止

2 个答案: