bash - 使用管道命令忽略 Bash 脚本中的 HUP 信号

Question

我有以下脚本监控 /tmp无限期目录，如果对该目录中的文件有任何操作，则文件名由 while 循环读取，并首先 a文件名中的字符替换为 b字符和此修改后的文件名记录到 test.log文件:

#!/bin/bash

trap ':' HUP
trap 'kill $(jobs -p)' EXIT

/usr/local/bin/inotifywait -q -m /tmp --format %f | 
  while IFS= read -r filename; do
    echo "$filename" | sed 's/a/b/' > test.log
  done

这是实际脚本的简化版本。我还有一个 Sys-V 类型的初始化脚本用于上面的脚本，因为我想保持 LSB 兼容，我的初始化脚本有 force-reload (如果服务支持，则重新加载配置。否则，重新启动服务。)向脚本发送 HUP 信号的选项。现在在执行 force-reload 之前，它执行 killproc -HUP test.sh , pstree 的输出如下:

# pstree -Ap 4424
test.sh(4424)-+-inotifywait(4425)
              `-test.sh(4426)
# 

执行 strace killproc -HUP test.sh 后子 shell 终止:

# pstree -Ap 4424
test.sh(4424)---inotifywait(4425)
# 

根据 strace , killproc已发送SIGHUP到流程 4424和 4426 , 但只有后者被终止。

这个带有 PID 4426 的子 shell 有什么意义？在我的示例中，即为什么首先创建它？另外，有没有办法忽略HUP信号？

Answer 1

管道命令在子shell中运行

问题的第一部分由 shell(在本例中为 Bash)在管道中运行命令的机制来解释。

管道是一个 FIFO(先进先出)单向进程间通信 (IPC) channel :它允许在一端写入字节(只写端)并从另一个(只读端)读取，而无需读取或写入物理文件系统。

管道 允许两个不同的命令通过匿名 或未命名(即，在文件系统中没有条目)相互通信管道。

当shell执行一个简单的命令时，该命令在shell的子进程中运行。如果不使用作业控制，则当子进程终止时，shell 将重新获得对终端的控制。

当两个命令在管道中运行时，管道中的两个命令将作为两个同时运行的独立子进程执行。

在 Unix 系统中，管道是使用 pipe(2) 系统调用创建的，它会创建一个新管道并返回一对文件描述符，其中一个指向 read 端，另一个到管道的写入端。

对于 GNU/Linux 系统上的 Bash，clone(2) 系统调用用于创建子进程。这允许子进程与其父进程共享文件描述符表，以便两个子进程都继承匿名管道的文件描述符，以便一个可以读取，另一个可以写入

在您的情况下，inotifywait 命令获取 PID 4425 并通过将其 stdout 连接到管道的文件描述符来写入管道的只写端写完。

同时，管道命令的右侧获取 PID，4426 并将其 stdin 文件描述符设置为管道只读端的文件描述符。由于管道右侧的子 shell 不是外部命令，因此代表子进程的名称与其父进程相同，test.sh。

有关详细信息，请参阅 man 7 pipe 和以下链接:

• Anonymous pipe, Wikipedia article
• Unix Pipeline, Wikipedia article

信号处理

我花了很长时间(实际上是几个小时的研究)才弄清楚为什么 SIGHUP 信号的陷阱没有被忽略。

我的所有研究表明，由 clone(2) 系统调用创建的子进程也应该能够共享父进程的信号处理程序表。

Bash 手册页还指出

Command substitution, commands grouped with parentheses, and asynchronous commands are invoked in a subshell environment that is a duplicate of the shell environment, except that traps caught by the shell are reset to the values that the shell inherited from its parent at invocation.

后来又说

Signals ignored upon entry to the shell cannot be trapped or reset. Trapped signals that are not being ignored are reset to their original values in a subshell or subshell environment when one is created.

这表明子 shell 不会继承未被忽略的信号处理程序。据我了解，您的 trap ':' HUP 行意味着 SIGHUP 信号被(有效地)忽略了(因为 : 内置函数除了返回成功外什么都不做)——并且反过来应该被管道的子 shell 忽略。

但是，我最终在 Bash 手册页中看到了关于 trap 的描述，它定义了 Bash 中 ignore 的含义:

If arg is the null string the signal specified by each sigspec is ignored by the shell and by the commands it invokes.

只需将 trap 命令更改为 trap '' HUP 即可确保忽略 SIGHUP 信号，对于脚本本身以及任何子 shell。