为何bash脚本1.sh在特定SIGHUP场景下未终止？两种操作差异解析

背景 #

根据《The Linux Programming Interface》中的内容，当shell终止时，会向所有进程组（包括前台和后台）发送SIGHUP信号，从而终止这些进程。但以下测试场景的行为与此结论相悖：

测试脚本 #

1.sh #

#!/bin/bash

for i in {1..10000}; do
    echo "$i in $0"
    sleep 1
done

2.sh #

#!/bin/bash
./1.sh &
for i in {1..10000}; do
    echo "$i in $0"
    sleep 1
done

操作步骤 #

• 打开终端，运行./2.sh
• 按下ctrl+c终止2.sh
• 直接关闭该终端
• 打开新终端，执行ps -ef | grep 1.sh

执行结果 #

root     4022351       1  0 19:15 ?        00:00:00 /bin/bash ./1.sh
root     4022492 4022423  0 19:16 pts/5    00:00:00 grep --color=auto 1.sh

疑问 #

为何1.sh仍在运行？而如果跳过步骤2，直接关闭终端窗口，1.sh也会被终止，这又是为什么？

原因解析 #

• 在非交互式shell中使用&运算符时，被修饰的进程会忽略SIGINT/SIGQUIT信号
• 若父进程已提前终止，对于交互式shell而言，该作业已完成，不会向&修饰的进程发送SIGHUP信号

因此，1.sh既忽略了SIGINT信号，又未收到SIGHUP信号，最终导致其持续运行。

内容的提问来源于stack exchange，提问作者shan