为什么SIGUSR1导致进程终止？

我对另一个问题的评论感到惊讶：

实际上，在启动后过早发送dd USR1信号（即，在bash脚本中，即启动后的行）实际上将终止它

有人可以解释为什么吗？

signals

并不是您的问题的答案，而是尝试一下这种方法：{ dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobs重现您所描述的效果。

— 吉比2012年

每个信号都有一个“默认配置”-进程在收到该信号时默认执行的操作。signal(7)手册页中有一张表格列出了它们：

Signal     Value     Action   Comment
──────────────────────────────────────────────────────────────────────
...
SIGUSR1   30,10,16    Term    User-defined signal 1
SIGUSR2   31,12,17    Term    User-defined signal 2

SIGUSR1并且SIGUSR2都具有默认操作Term-进程终止。dd注册一个处理程序以拦截信号并对其进行一些有用的处理，但是如果您发信号的速度太快，它还没有时间注册该处理程序，因此将执行默认操作

— 迈克尔Mrozek
source

我希望我能两次被了解到这种晦涩的地方。删除明确的信号处理程序后，看到进程随机死亡是令人不安的。

— DeaconDesperado '16

有什么实际的方法可以控制这种比赛状况，而不是仅仅睡一段合理的时间（〜0.5-1秒）？（我的意思是，除了像strace在shell脚本中捕获和解析输出之类的荒谬之举外……）

— AdrianGünter18年

我的shell脚本运行正常。但是由于可能突然停止工作！：我现在已经关闭了。发送kill -s SIGUSR1 $ PARENT_PID的子进程现在变得太快了吗？大父母认为父母已正常终止，但父母仍在执行循环。这是一个很好的帖子。我整天大部分时间都在尝试解决这个问题。

— Kemin Zhou