使用管道命令忽略 Bash 脚本中的 HUP 信号
Ignore HUP signal in Bash script with pipe commands
我有以下脚本无限期地监视 /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
后childshell终止:
# pstree -Ap 4424
test.sh(4424)---inotifywait(4425)
#
根据 strace
,killproc
发送 SIGHUP
到进程 4424
和 4426
,但只有后者被终止。
在我的示例中,这个 child-shell 和 PID 4426
有什么意义,即为什么首先要创建它?另外,有没有办法忽略HUP
信号?
管道命令在子运行shell
中
你问题的第一部分是通过管道中的 shell(在本例中为 Bash)运行s 命令的机制来解释的。
一个pipe是一个FIFO(先进先出)单向进程间通信(IPC)通道:它允许在一端(只写端)写入字节并从另一端(只读端)读取而不需要读取从或写入物理文件系统。
一个管道允许两个不同的命令通过匿名或未命名[=83=相互通信](即,在文件系统中没有条目)管道。
当shell执行简单命令时,该命令在shell的子进程中是运行。如果不使用作业控制,则在子进程终止时 shell 重新获得终端的控制。
当管道中有两个命令 运行 时,管道中的两个命令都作为两个单独的 子进程 执行,其中 运行 并发。
在 Unix 系统中,管道是使用 pipe(2)
系统调用创建的,它会创建一个新管道和 returns 一对文件描述符,其中一个引用 read 端,另一个到管道的 write 端。
在 GNU/Linux 系统上使用 Bash,clone(2)
系统调用用于创建子进程。这允许子进程与其父进程共享 table 文件描述符,以便两个子进程都继承 匿名管道 的文件描述符,以便可以读取给它,另一个可以写给它。
在您的例子中,inotifywait
命令获取 PID 4425,并通过将其 stdout
连接到写入端的文件描述符来写入管道的只写端。
同时,管道命令的右侧获取 PID,4426 及其 stdin
文件描述符设置为管道只读端的文件描述符。由于管道右侧的 subshell 不是外部命令,因此表示子进程的名称与其父进程相同,test.sh
.
有关详细信息,请参阅 man 7 pipe
和以下链接:
信号处理
我花了很长时间(实际上是几个小时的研究)才弄清楚为什么 SIGHUP 信号的陷阱没有被忽略。
我的所有研究表明,由 clone(2)
系统调用创建的子进程也应该能够共享父进程的 table 信号处理程序。
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 信号被(有效地)忽略了(因为 :
内置除了 return 成功之外什么都不做)——并且应该被忽略管道的 subshell.
但是,我最终在 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 信号,对于脚本本身以及任何子 shells.
我有以下脚本无限期地监视 /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
后childshell终止:
# pstree -Ap 4424
test.sh(4424)---inotifywait(4425)
#
根据 strace
,killproc
发送 SIGHUP
到进程 4424
和 4426
,但只有后者被终止。
在我的示例中,这个 child-shell 和 PID 4426
有什么意义,即为什么首先要创建它?另外,有没有办法忽略HUP
信号?
管道命令在子运行shell
中你问题的第一部分是通过管道中的 shell(在本例中为 Bash)运行s 命令的机制来解释的。
一个pipe是一个FIFO(先进先出)单向进程间通信(IPC)通道:它允许在一端(只写端)写入字节并从另一端(只读端)读取而不需要读取从或写入物理文件系统。
一个管道允许两个不同的命令通过匿名或未命名[=83=相互通信](即,在文件系统中没有条目)管道。
当shell执行简单命令时,该命令在shell的子进程中是运行。如果不使用作业控制,则在子进程终止时 shell 重新获得终端的控制。
当管道中有两个命令 运行 时,管道中的两个命令都作为两个单独的 子进程 执行,其中 运行 并发。
在 Unix 系统中,管道是使用 pipe(2)
系统调用创建的,它会创建一个新管道和 returns 一对文件描述符,其中一个引用 read 端,另一个到管道的 write 端。
在 GNU/Linux 系统上使用 Bash,clone(2)
系统调用用于创建子进程。这允许子进程与其父进程共享 table 文件描述符,以便两个子进程都继承 匿名管道 的文件描述符,以便可以读取给它,另一个可以写给它。
在您的例子中,inotifywait
命令获取 PID 4425,并通过将其 stdout
连接到写入端的文件描述符来写入管道的只写端。
同时,管道命令的右侧获取 PID,4426 及其 stdin
文件描述符设置为管道只读端的文件描述符。由于管道右侧的 subshell 不是外部命令,因此表示子进程的名称与其父进程相同,test.sh
.
有关详细信息,请参阅 man 7 pipe
和以下链接:
信号处理
我花了很长时间(实际上是几个小时的研究)才弄清楚为什么 SIGHUP 信号的陷阱没有被忽略。
我的所有研究表明,由 clone(2)
系统调用创建的子进程也应该能够共享父进程的 table 信号处理程序。
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 信号被(有效地)忽略了(因为 :
内置除了 return 成功之外什么都不做)——并且应该被忽略管道的 subshell.
但是,我最终在 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 信号,对于脚本本身以及任何子 shells.