信号 · XB 现场笔记

进程组选择信号接收者，不等于进程家族树

Fri, 24 Sep 2027 00:00:00 +0000

进程组是内核维护的一组进程，通过进程组编号 PGID 标识，可用于向一个作业投递信号等操作。父子关系与组成员关系是两个维度：有亲缘关系的进程可以属于不同组，组长也不必始终存活，其他成员仍可继续属于原组。理解这些关系，才能判断一个控制动作到底覆盖哪些进程，以及某个进程退出意味着什么。

零号信号可以在不投递信号的情况下检查存在性与权限，但不是存活或完成确认。僵尸进程仍可能存在，检查之后目标状态也可能变化。因此，应保留本例通过等待回收确认完成的步骤，不能用一次成功的权限探测替代退出结果，更不能据此判断业务工作已经安全结束。

坏掉的样子

向单个进程发信号，不会自动向它的所有子进程发信号。向进程组发信号，选择的是当前组成员，也不是整棵后代树。创建新会话或新组的子进程，可能已经位于目标范围之外；反过来，多个兄弟进程可以刻意共享一个组，即使任何一个都不是另一个的父进程。进程树图不能直接替代组成员清单。

组投递也不保证所有接收者作出相同响应。一个成员可能采用默认动作，另一个安装处理函数，还有成员可能忽略或阻塞允许处理的信号。因此，组操作不会自动形成原子停止，也不能证明组内全部工作完成。每个进程的信号处理方式和应用关停协议仍然决定最终结果，需要分别观察投递、响应与退出。

组长退出不等于整个组退出。只要还有成员，PGID 就可能继续有效，即使组长已经被父进程回收。只观察组长状态的监督程序，可能在成员仍运行时报告结束。组身份应与实际生命周期管理结合，不能被当作一批启动工作永久不变的标识，也不能单凭领导进程消失就推断所有资源都已释放。

快速验证

把脚本保存为 groups.py，在具有 Python 3.11 或更新版本的一次性 Linux 环境中运行 python3 groups.py。本轮在 Linux 6.18.44 和 Python 3.12.14 上重新执行了该样本。process_group 选项在执行程序前安排进程组，start_new_session 请求新会话。所有收到信号的进程，都由此样本创建：

import os,signal,subprocess,sys

worker=r'''
import os,signal,sys
if sys.argv[1]=='ignore-term':signal.signal(signal.SIGTERM,signal.SIG_IGN)
signal.signal(signal.SIGUSR1,lambda *_:print('USR1',flush=True))
print(os.getpid(),os.getpgrp(),os.getsid(0),flush=True)
while True:signal.pause()
'''
children=[]
def launch(role,**settings):
 process=subprocess.Popen([sys.executable,'-c',worker,role],stdout=subprocess.PIPE,stderr=subprocess.PIPE,text=True,**settings)
 children.append(process)
 identity=tuple(map(int,process.stdout.readline().split()))
 assert len(identity)==3 and identity[0]==process.pid
 return process,identity
try:
 leader,first=launch('default',process_group=0)
 member,second=launch('ignore-term',process_group=leader.pid)
 outsider,third=launch('default',start_new_session=True)
 group=leader.pid
 assert first[1]==second[1]==group and first[2]==second[2]==os.getsid(0)
 assert third==(outsider.pid,outsider.pid,outsider.pid)
 assert group!=os.getpgrp() and third[1]!=group
 print('two sibling children share a group; another sibling starts a separate session and group')
 os.killpg(group,signal.SIGTERM)
 assert leader.wait(timeout=5)==-signal.SIGTERM
 assert member.poll() is None and outsider.poll() is None
 assert os.getpgid(member.pid)==group
 print('group TERM terminates the default recipient, leaves the ignoring member alive, and excludes the other group')
 os.killpg(group,signal.SIGUSR1)
 assert member.stdout.readline().strip()=='USR1'
 print('the group remains addressable after its leader has exited and been reaped')
 os.killpg(group,signal.SIGKILL)
 assert member.wait(timeout=5)==-signal.SIGKILL
 assert outsider.poll() is None
 outsider.terminate();assert outsider.wait(timeout=5)==-signal.SIGTERM
 print('cleanup reaps all three children; signaling a group did not signal the whole family tree')
finally:
 for process in children:
 if process.poll() is None:process.kill();process.wait()

第一个子进程新建进程组，PGID 等于自己的 PID。第二个子进程在控制进程所在会话中加入该组。第三个子进程创建独立会话，同时成为会话首领和进程组长。脚本读取真实 PID、PGID 和会话编号，而不是仅根据请求参数推测安排已经生效，这让实验身份与操作目标可以直接核对。

三个进程都是同一控制进程启动的兄弟。前两个共享信号目标，第三个不在其中，因此能明确展示父子关系与组成员关系的区别。脚本还确认目标 PGID 不等于控制进程自己的组，避免组操作意外命中发起实验的进程。这里控制的是自己创建并已确认身份的对象，没有使用猜测的外部进程编号。

向共享组发送 TERM，采用默认处理方式的第一个子进程终止。第二个刻意忽略 TERM，继续存活；组外子进程同样仍运行。控制进程等待并回收第一个子进程，再确认存活成员仍以已退出组长的 PID 作为 PGID。这个结果直接说明，领导进程的生命周期与组中最后一个成员的生命周期并不相同。

之后向该组发送 USR1，存活成员安装的处理函数打印确认消息，证明组长退出后进程组仍可寻址。对于这次请求，样本检查具体处理函数的响应，没有只依据发送调用成功就推断应用已经执行动作。信号可以作为触发机制，但需要业务确认时，应另外设计可观察结果。

最后，KILL 终止剩余组成员，独立会话里的子进程仍然存活。控制进程单独终止第三个子进程，并回收三者，断言失败时也会清理。这验证了选择性组投递和不同处理方式，不需要控制终端，也没有向宿主机无关进程发送信号。实验完成是通过等待实际退出确认，而不是发完信号就结束。

分清会话、终端与监督关系

setpgid 修改成员关系时，受会话和进程状态限制。setsid 为符合条件的调用者创建新会话和进程组，现有进程组长不能直接调用成功。创建会话不会改变父进程是谁。重新归属父进程、关联终端与选择进程组，是运行管理中相关的概念，却不是一个可以相互替换的动作，不能把它们都笼统叫作脱离父进程。

启用作业控制的交互 shell，通常把管道放在独立组中，并设置终端的前台 PGID。终端驱动把配置的控制字符信号投递给前台组。非交互 shell 并不普遍为每条管道创建独立组，因此需要检查真实启动模式，而不能把交互终端的行为直接套到所有脚本、服务和容器入口上。

信号权限仍按接收进程判断。Linux 文档中的组发送成功，只表示至少向一个符合条件的进程投递，并不是每位成员都已确认。需要确定完成时，应使用合适的服务管理器或明确的子进程管理协议，并观察退出或应用确认。组目标有助于控制作业，却不能替代追踪真实成员及其最终结果。

来源

setpgid(2)，进程组成员、继承与会话限制，已核验 2026-10-15。
setsid(2)，创建会话和进程组以及组长限制，已核验 2026-10-15。
kill(2)，面向进程组的投递、权限检查与成功语义，已核验 2026-10-15。
credentials(7)，进程编号、进程组、会话与控制终端，已核验 2026-10-15。

Shell 的 trap 把信号转成一次清理动作

Tue, 12 Jan 2027 00:00:00 +0000

trap 让 Shell 为某个信号或自身事件安排动作，适合删除临时文件、协调退出，但不会让中断变成原子操作，也无法保证任何终止方式都能完成清理。在 Bash 中，trap 是内建命令，EXIT 是 Shell 事件，而不是操作系统信号。可靠的设计需要明确处理哪些出口，并保留执行为什么结束的证据，不能仅凭注册了一次处理器就断言资源一定会被回收。

信号处理与退出清理分开

trap 'cleanup' INT TERM 会替换这些信号的默认动作。如果处理器只是返回，Shell 可能继续执行；安装处理器并不天然等于启动关停。一种明确的 Bash 写法是在信号处理器中主动退出，再让统一的退出处理器负责清理。正常执行到末尾、显式调用退出命令，也会经过这个出口，从而减少各业务分支之间重复的资源回收逻辑。

从函数或被点命令加载的文件返回，不等于结束整个 Shell。普通执行脚本里的顶层 return 也不是通用退出方式。此外，不能跨 Shell 假定未处理的致命信号一定会触发退出清理。应明确处理准备支持的终止信号，并使用服务真正采用的解释器测试，而不是在交互终端里试过一次便推广到所有启动环境。

trap - INT 恢复默认动作，trap '' INT 则忽略信号，两者策略不同。非交互 Shell 还可能从启动者继承被忽略的信号，而且无法重新捕获或重置，所以启动路径也是行为的一部分。需要确认实际安装的动作时，可以检查 trap -p 输出；配置中写过处理器，与当前 Shell 最终持有什么处理器，仍然需要区分。

保留最初的退出原因

进入退出处理器后，应先保存 $?，避免后面的命令覆盖它。清理末尾固定执行 exit 1，会把成功改成失败，也会抹掉原来不同的错误码。使用保存的状态退出，才能保留触发收尾的原始结果。清理本身失败时仍应输出可见诊断，并制定明确策略，尤其要说明主工作成功而清理失败时最终如何报告，不能把这两种结果混成一句“脚本结束”。

示例为已处理的中断选择一百三十，为终止请求选择一百四十三，沿用 Bash 常见的信号状态约定。但这是处理器主动执行的普通退出，不证明进程真的被操作系统信号直接杀死；使用进程接口的监督程序能够区分两者。短暂清理期间关闭退出陷阱、忽略中断和终止请求，是为了避免这些处理器重入清理逻辑，并不是无限期屏蔽关停的建议。

这段清理代码有意优先保留最初的退出状态。删除命令即使报告错误，也不会改变已保存的结果，因此零退出码不是清理完成的独立证明。若残留资源会产生后果，需要另外测试清理失败，并决定是否报告不同的失败、进行安全重试，或保留恢复所需证据。

坏掉的样子

强制杀死信号无法捕获，停止信号也不能捕获，更不能把停止视作清理机会。断电、崩溃和强制终止都可能留下资源。因此，陷阱不能替代崩溃安全写入、事务更新或单独定义的恢复流程。删除目标必须限制在脚本拥有的路径内；一个尚未初始化完成的变量，绝不能意外变成宽泛删除范围。清理动作的权限边界与正常业务操作同样需要检查。

执行时机也有差别。Bash 等待同步前台命令结束时，可以推迟执行已经捕获的信号处理器；通过内建等待命令等待异步任务时，被捕获的信号则会先打断等待，随后进入处理器。因此，注册陷阱并不意味着任意阻塞操作都能立即响应关停，更不能据此承诺固定的退出时限。长时间外部工作需要结合真实等待方式验证。

终端中的 Ctrl-C 会把中断信号发给前台进程组，而向单个进程编号发送信号只针对那个进程。于是，同一个子进程可能在一种测试中收到信号，在另一种测试中没有收到。管理工作进程的脚本，应分别定义信号转发、等待结束和资源归属；不能杀掉不相关进程，也不能把 Shell 已经退出当作所有后代进程都已停止的证据。

快速验证

使用 Python 3、Bash 及常见 Unix 工具运行下面的示例。每个分支启动一个独立 Bash，并在私有临时目录中创建一个文件；信号只发给这层新 Shell 自身。外层临时目录由 Python 管理，强制终止分支故意留下的文件，最后也由这个外层管理器删除，不会把残留留在用户工作区。

import os
import signal
import subprocess
import tempfile
from pathlib import Path

script = r'''
demo_file=$1
cleanup() {
 demo_status=$?
 trap - EXIT
 trap '' INT TERM
 rm -f -- "$demo_file"
 printf 'cleanup=%s\n' "$demo_status"
 exit "$demo_status"
}
trap cleanup EXIT
trap 'exit 130' INT
trap 'exit 143' TERM
: > "$demo_file" || exit 1
case "$2" in
 normal) exit 7 ;;
 *) kill "-$2" "$$" ;;
esac
exit 99
'''
with tempfile.TemporaryDirectory(prefix="bash-trap-demo-") as directory:
 for mode, expected in [("normal", 7), ("TERM", 143),
 ("INT", 130), ("KILL", -signal.SIGKILL)]:
 target = Path(directory) / mode
 result = subprocess.run(
 ["bash", "--noprofile", "--norc", "-c", script,
 "trap-demo", str(target), mode],
 env=dict(os.environ, BASH_ENV=""),
 text=True, capture_output=True, timeout=5,
 )
 cleaned = result.stdout == f"cleanup={expected}\n"
 remains = target.exists()
 assert result.returncode == expected, result
 assert (cleaned, remains) == (mode != "KILL", mode == "KILL"), result
 assert not result.stderr, result
 print(f"{mode}: rc={result.returncode} cleaned={cleaned} remains={remains}")

前三种情况应分别返回七、一百四十三和一百三十，观察到清理输出，且文件已经不存在。强制杀死分支应得到 Python 表示信号终止的负数返回码，通常为负九，没有清理输出，同时文件仍存在；若由 Shell 调用，通常会把同一终止表示为一百三十七。这种差异来自结果表示方式，不能误判成实验不一致。

这组结果验证了原退出状态得到保留，也验证了无法捕获的终止确实绕过清理。它没有测试向工作进程转发信号、终端前台进程组，或长时间同步命令造成的处理延迟。真实脚本涉及这些行为时，需要补上对应环境中的观察，而不是把这个单进程实验当作整套进程管理机制已经验收。

来源

Bash 信号，等待期间的信号处理及前台进程组，已核验 2026-09-07。
POSIX trap，退出事件、继承的信号处置及陷阱动作，已核验 2026-09-07。

信号具有处理方式、掩码和投递规则

Mon, 23 Nov 2026 00:00:00 +0000

信号依据内核规定的投递规则，把事件通知给进程或线程。信号处理方式可以选择默认动作、安装处理函数，或者在允许时忽略；线程掩码则能阻塞符合条件的信号，让它们暂时保持待处理。当程序似乎漏掉重复通知，或者没有按预期停止时，需要分别检查处理方式、阻塞状态和待处理状态，不能把这些不同层面统称为“有没有收到信号”。

坏掉的样子

普通信号不是可靠事件计数器。同一种标准信号已经处于待处理状态时，随后多次发生可能合并。如果应用把每次 SIGUSR1 都理解为一个排队任务，就可能丢失这个计数关系。实时信号具有排队语义，但资源仍然有限，也需要明确的应用协议；不能仅因为名字里有实时，就假定它适合无限量承载业务消息。

信号名称不保证应用功能。某些守护进程约定 SIGHUP 表示重载，但它的默认动作是终止。SIGTERM 默认也会终止，只有应用实现了相应行为，它才成为优雅关停请求。发送成功不能证明配置已经重载，也不能证明在途工作已经排空。控制方必须观察目标实际响应，而不是把投递结果当作业务操作结果。

SIGKILL 与 SIGSTOP 不能捕获、忽略或阻塞。KILL 不给应用执行清理的机会，但也不应被描述为在每种内核状态下都保证瞬时释放资源。监督者仍需观察实际完成。使用符号名称也更清晰，不能假定所有平台上的信号编号都完全一致；信号数字与进程退出状态还可能由工具采用不同方式表示。

快速验证

把下面脚本保存为 signals.py，在一次性 Linux 环境中运行 python3 signals.py。原始记录使用 Linux 6.12.76 和 Python 3.11.2；本轮在 Linux、Python 3.12.14 上重新执行了增加子进程就绪超时的实验。脚本只向自身和自己创建的子进程发送信号，恢复原始掩码，并把清理标记限制在临时目录中：

from pathlib import Path
from tempfile import TemporaryDirectory
import errno,os,select,signal,subprocess,sys

watched={signal.SIGUSR1,signal.SIGRTMIN}
old=signal.pthread_sigmask(signal.SIG_BLOCK,watched)
try:
 for _ in range(5):os.kill(os.getpid(),signal.SIGUSR1)
 assert signal.SIGUSR1 in signal.sigpending()
 assert signal.sigwait({signal.SIGUSR1})==signal.SIGUSR1
 assert signal.sigtimedwait({signal.SIGUSR1},0) is None
 for _ in range(3):os.kill(os.getpid(),signal.SIGRTMIN)
 for _ in range(3):assert signal.sigtimedwait({signal.SIGRTMIN},0).si_signo==signal.SIGRTMIN
 assert signal.sigtimedwait({signal.SIGRTMIN},0) is None
 print('five blocked standard signals coalesce into one; three blocked real-time signals remain queued')
finally:signal.pthread_sigmask(signal.SIG_SETMASK,old)
for sig in [signal.SIGKILL,signal.SIGSTOP]:
 try:signal.signal(sig,signal.SIG_IGN)
 except OSError as error:assert error.errno==errno.EINVAL
 else:raise AssertionError('uncatchable signal accepted a disposition change')
old=signal.pthread_sigmask(signal.SIG_BLOCK,{signal.SIGKILL,signal.SIGSTOP})
assert not {signal.SIGKILL,signal.SIGSTOP}&signal.pthread_sigmask(signal.SIG_BLOCK,set())
signal.pthread_sigmask(signal.SIG_SETMASK,old)
print('SIGKILL and SIGSTOP cannot be ignored or added to the blocked mask')
worker=r'''
from pathlib import Path
import signal,sys
if int(sys.argv[1]):signal.signal(signal.SIGTERM,lambda *_:sys.exit(0))
try:
 print('ready',flush=True)
 while True:signal.pause()
finally:Path(sys.argv[2]).write_text('cleanup')
'''
with TemporaryDirectory(prefix='xbcatm-signals-') as directory:
 for name,sig,handled,expected,cleaned in [
 ('hup-default',signal.SIGHUP,False,-signal.SIGHUP,False),
 ('term-default',signal.SIGTERM,False,-signal.SIGTERM,False),
 ('term-handled',signal.SIGTERM,True,0,True),
 ('kill',signal.SIGKILL,True,-signal.SIGKILL,False)]:
 marker=Path(directory)/name
 process=subprocess.Popen([sys.executable,'-c',worker,str(int(handled)),str(marker)],stdout=subprocess.PIPE,stderr=subprocess.PIPE,text=True)
 try:
 assert select.select([process.stdout], [], [], 5)[0], 'child readiness timed out'
 assert process.stdout.readline().strip()=='ready'
 os.kill(process.pid,sig);output,error=process.communicate(timeout=5)
 assert process.returncode==expected,(name,process.returncode,error)
 assert marker.exists()==cleaned,name
 print(name,'returncode',process.returncode,'cleanup',cleaned)
 finally:
 if process.poll() is None:process.kill();process.wait()

脚本先阻塞 SIGUSR1，向自己发送五次，再确认它待处理。一次同步等待取走信号后，第二次零超时等待没有结果。先阻塞再发送，让这个对照具有确定性。它证明的是待处理普通信号的合并规则，而不是根据异步回调碰巧打印几次，去猜测信号是否丢失或程序调度是否足够快。

接着在阻塞状态下发送三次 SIGRTMIN，三次等待分别取到一个，之后才为空。这通过同步消费直接比较排队规则。实验没有测量队列容量、不同实时信号编号之间的优先级，也没有验证应用负载随信号传递。正文只依据实际覆盖的现象解释，避免把基本排队对照扩大成完整消息系统保证。

尝试忽略 KILL 和 STOP，均得到 EINVAL；尝试把它们加入阻塞掩码，实际掩码中也没有这些成员。这里区分处理方式修改被拒绝，与掩码请求里不可阻塞成员被忽略两种行为。两种操作都不会让应用获得控制这两个信号的能力，因此不能把函数返回方式相似或不同当作信号已经被阻塞的证明。

随后四个子进程案例分离投递和清理。默认 HUP 与默认 TERM 都终止子进程，不会生成 Python finally 中的标记。明确安装 TERM 处理函数的子进程通过 Python 退出，并写出标记。最后一个子进程具有相同 TERM 处理函数，但收到 KILL 后没有执行清理。处理一种信号，不会让它也能处理另一种不可捕获信号。

Python subprocess 用负的终止信号编号表示信号终止，主动处理 TERM 的案例则正常返回零。这是 Python 的进程状态表示，不是所有 shell 通用的退出码规则。脚本同时检查状态与标记，避免只凭其中一项推断清理发生。真实应用也应把控制动作、终止原因和工作完成结果分别观察。

把工作放到适合的执行上下文

原生信号处理函数中，只适合执行异步信号安全操作。普通日志、内存分配以及许多库调用，可能在程序被中途打断时死锁或破坏状态。常见设计是记录最小通知，再让正常执行流程完成协调关停；具体通知机制应匹配运行时和受支持的事件循环，而不是在信号处理函数里直接处理所有业务善后。

Python 处理函数通过解释器信号机制在主线程执行，不是在底层 C 处理函数里直接运行任意 Python。这解释了小型 TERM 案例为何可以抛出 SystemExit，却不能据此在 C handler 中做任意工作，也不能保证长时间运行的原生操作会及时让出控制，使 Python 清理立刻执行。运行时边界是解释实验结果的一部分。

控制服务时，应定义预期响应、观察机制和合适期限。重载要能证明新配置生效；关停要按策略停止接入、完成或放弃在途工作，并报告结束。升级信号会改变终止行为，却不能补回应用从未实现的清理逻辑。正确监督依赖实际结果，而不是仅依赖一次投递成功或一个听起来温和的信号名字。

来源

signal(7)，默认动作、掩码、普通信号合并与实时信号队列，已核验 2026-10-15。
signal-safety(7)，原生信号处理函数的异步信号安全限制，已核验 2026-10-15。
Python 3.11 signal documentation，Python 处理函数执行、同步等待与信号掩码，已核验 2026-10-15。
kill(2)，信号投递权限与返回语义，已核验 2026-10-15。