题干与适用场景
一个 Linux HTTP 服务运行在 Kubernetes 容器中。滚动更新时，它收到 SIGTERM，终止宽限期为 30 秒；此时有 200 个进行中的请求、两个子工作进程和一个后台任务消费者。请从信号投递开始设计完整退出协议，并解释 SIGTERM 与 SIGKILL 的行为、信号处理函数的安全边界、流量排空、任务与子进程处理、截止时间和验证方法。
30 秒和 200 个请求是面试场景输入。Kubernetes 常见的 Pod 默认终止宽限期是 30 秒，但生产值应由请求时长、清理耗时、负载语义和可用性要求共同确定。本题可以设置 25 秒的内部排空截止时间，预留五秒做最终清理并吸收调度波动。25 加 5 只是场景内的工程预算，不是平台保证。
题目的核心是 Linux 进程生命周期协议，Kubernetes 和 HTTP 提供运行背景。高质量回答需要追踪信号如何到达目标进程，如何安全地触发状态转换，如何控制新任务与进行中任务，以及如何证明进程能在截止时间内结束。
面试官考察点
第一项是信号语义。进程可以捕获、阻塞或忽略 SIGTERM，它的默认动作是终止。一旦应用捕获了它，应用就要在清理后主动结束。SIGKILL 不能被捕获、阻塞或忽略，因此不会留下清理机会。标准信号也不是可靠队列：同一种标准信号在等待期间重复到达时，可能只保留一个待处理实例。
第二项是信号能否到达服务。容器使用 shell 形式的入口命令时，PID 1 可能是 /bin/sh -c，实际程序收不到预期的 SIGTERM。通常应使用 exec 形式的入口；必须使用包装脚本时，脚本最后应执行 exec。创建子进程的服务还要负责转发终止信号并回收子进程；应用无法承担 PID 1 职责时，可以配置合适的微型 init。
第三项是异步信号安全边界。原始 C 信号处理函数可能在任意指令处打断正常执行。在其中调用 printf、分配内存、获取互斥锁、关闭整套应用对象或刷新客户端库，可能造成死锁或状态损坏。处理函数只应通过信号安全操作发布最小通知，正常控制路径负责清理。
第四项是退出顺序。服务先变为未就绪并停止接收新工作，再在截止时间内完成或取消已接收的工作。后台任务消费者需要停止取新任务，同时保持租约语义正确；请求使用完共享依赖后才能关闭依赖；子进程需要终止并回收；日志与链路数据只能限时刷新；进程应在编排器升级为 SIGKILL 之前退出。
最后一项是运行证据。只测信号处理函数，无法证明容器 PID 结构、端点摘除、连接行为、任务重投、子进程回收和宽限期都正确。回答应包含容器级和滚动更新级测试，并给出可观测的通过条件。
回答前需要澄清的问题
- 谁发送信号，目标 PID 是谁？ 确认容器运行时、停止信号、入口命令、包装脚本，以及应用是否为 PID 1。
- 谁在消耗这 30 秒？ Kubernetes 的
preStop钩子也在同一个终止宽限期内执行，它会减少应用可用的排空时间。 - “进行中”包含哪些工作？ 区分已接收请求、没有请求的长连接、流式响应、升级连接和应用队列；它们的结束策略不同。
- 服务能否立即拒绝新工作？ 确认就绪探针、负载均衡器、监听器、服务网格和直连调用方。就绪状态传播需要时间。
- 请求时长和重试契约是什么？ 短的幂等读取可以完成；长上传或带副作用的写入可能需要取消、移交或幂等键。
- 后台任务如何确认归属？ 澄清确认时机、可见性超时或租约、心跳、重投和幂等性。没有这些信息，直接“停掉 worker”并不安全。
- 谁管理子工作进程？ 确认父进程能否向进程组发信号、子进程是否有自己的退出流程，以及谁调用
waitpid。 - 运行时如何暴露信号？ 专用
sigwait线程、事件循环回调和原始 C 处理函数有不同的安全边界，应说明真实实现。 - 怎样才算成功？ 明确新任务接收数、完成和取消结果、重复副作用、僵尸进程、退出耗时与强制终止率的验收标准。
30 秒回答框架
“我先确认 exec 形式入口能把 SIGTERM 交给应用。原始处理函数只唤醒正常控制路径；控制路径让就绪失败，停止接收请求和任务，并用 25 秒内部截止时间排空已接收工作。随后安全取消剩余工作，终止并回收两个子进程，限时刷新数据，在 30 秒宽限期结束前退出。SIGKILL 不会执行清理。我会在并发请求和任务下给真实容器发信号，验证接收截止、重试语义、子进程回收和退出耗时。”
这个框架确定了主流程。深入回答还要覆盖多线程信号投递、被中断的系统调用、重复退出请求，以及端点摘除与监听器停止接收之间的差别。
分步骤深入解答
先检查投递路径。使用可执行文件形式的 ENTRYPOINT 或 CMD，让应用直接收到运行时的停止信号。包装脚本确有必要时，最后执行 exec "$@"。不要只看 Dockerfile，要检查运行中的容器：确认 PID 1、命令行、父子进程关系和停止信号。对容器执行真实 SIGTERM 的滚动更新测试才是最终证据。
先初始化唤醒机制，再安装处理函数；先安装处理函数，再把就绪状态设为成功。一个接近 C 的示意实现可以使用非阻塞 self-pipe：
static volatile sig_atomic_t stop_requested = 0;
static int wake_fd; /* 在 sigaction 前初始化为非阻塞 */
static void on_term(int signo) {
int saved_errno = errno;
stop_requested = 1;
const unsigned char byte = 1;
(void)write(wake_fd, &byte, sizeof byte);
errno = saved_errno;
}write 属于异步信号安全函数。文件描述符设为非阻塞后，通知已经填满管道时，处理函数不会等待；即使新字节没写进去，标志位仍保存了退出状态。处理函数不打印日志、不分配内存、不加锁、不等待子进程，也不调用应用客户端。普通事件循环读取管道并推进一个可重复执行的退出状态机。
多线程服务还可以采用另一种模式：创建工作线程前先阻塞终止信号，再由一个专用线程调用 sigwait，或在 Linux 上使用 signalfd。信号处置方式是进程级共享的，每个线程有独立信号掩码。发给进程的信号可以落到任意没有阻塞它的线程。在线程启动前统一信号掩码，并集中同步接收信号，可以把异步处理函数移出应用代码。
不要只依赖系统调用被信号打断来唤醒服务。不同接口以及是否设置 SA_RESTART，会决定阻塞调用是自动重启还是返回 EINTR。self-pipe、事件描述符、运行时信号通道或专用信号线程提供明确唤醒路径。退出阶段的每一个阻塞等待也要有截止时间。
用明确状态驱动服务：
RUNNING（运行）
--SIGTERM--> QUIESCING（停止接收）
--接收入口关闭--> DRAINING（排空）
--工作完成或到达 25 秒--> FINALIZING（收尾）
--子进程回收且限时刷新完成--> EXITED（退出）从 RUNNING 出发的转换必须是原子且幂等的。第一次 SIGTERM 记录开始时间和截止时间。第二次 SIGTERM 不应重新创建一套清理流程，也不能再次关闭同一资源。团队可以规定第二次信号只做记录，也可以规定它缩短排空时间，但行为必须明确且经过测试。
进入 QUIESCING 后，先让就绪探针失败，并立即阻止新的应用工作进入。Kubernetes 会把正在终止的端点标为未就绪，但控制面和代理传播有延迟。应用应关闭监听 socket、停止 accept，或让接收层对尚未越过接收边界的请求返回可重试结果。已经接收的连接可以继续排空。HTTP keep-alive 要单独处理，避免旧连接在退出开始后继续无限提交新请求。
后台消费者在同一边界停止拉取新任务。已经拿到租约的任务，只有在截止时间前能安全完成时才继续；否则应按队列契约停止心跳、释放租约或执行 nack，让其他 worker 能重试。持久完成后才能确认任务。外部副作用需要幂等键或事务状态转换，因为进程可能在外部写入完成后、确认任务前被强制终止。
进入 DRAINING 后，用计数器或注册表跟踪已接收工作，并在它们完成前保留所需依赖。请求处理器还在使用数据库连接池、缓存客户端或观测导出器时，不能提前关闭这些资源。到达 25 秒内部截止时间后，按协议取消剩余工作：停止流式传输、传播取消信号、尽可能返回定义好的响应，并保持状态可重试。余下五秒用于取消回调、子进程回收、最终状态写入和调度波动。
两个子工作进程应先停止输入，再接收约定的终止信号，父进程在截止时间内等待。如果父进程独占一个进程组，可以向该组发信号，同时避免影响无关进程。每个退出的子进程都要用 waitpid 回收，防止出现僵尸进程。微型 init 可以帮助无法承担 PID 1 职责的应用转发信号和回收子进程，但它不会替应用定义请求和任务语义。
进入 FINALIZING 后，写入最后的退出指标，并在严格时间预算内刷新日志和链路数据。观测信息有助于解释强制退出，但不可用的观测后端不能耗尽整个宽限期。按依赖顺序关闭剩余资源，优雅结束时返回零状态。如果进程错过平台截止时间，Kubernetes 最终会要求运行时发送 SIGKILL；此后不会运行处理函数、延迟执行块或退出钩子。
信号适合作为控制通知，不适合承载工作。标准信号可能合并、携带信息有限，并可能在意外代码位置到达。任务、重试和持久归属应放在队列或状态存储中，信号只负责启动或升级本地生命周期转换。
验证要覆盖生产使用的同一边界：
- 构建真实镜像，检查 PID 1，启动服务，然后向容器发送
SIGTERM，不要调用内部退出接口代替。 - 保持 200 个混合时长请求，其中既有 25 秒内能完成的工作，也有必须取消的工作。断言截止点之后没有新请求被接收，且每个已接收请求都有明确结束结果。
- 确认就绪状态失败，并在端点传播后，旧 Pod 不再接收滚动更新流量。另测一条直连连接，独立验证监听器接收边界。
- 在终止期间运行带租约的后台任务。验证完成任务只确认一次，未完成任务可以重试，重复投递不会产生重复业务副作用。
- 验证两个子进程都收到终止通知、在截止时间前结束并被回收，检查进程表中没有僵尸进程。
- 再发送一次
SIGTERM，证明清理幂等；另用SIGKILL证明系统没有依赖清理钩子，并验证持久任务仍能恢复。 - 记录
shutdown_started、接收状态、进行中数量、排空超时、子进程状态、退出耗时和强制终止。优雅退出达到 30 秒就判定测试失败。
高质量示范回答
“我会先从容器边界检查。入口使用 exec 形式，并在运行时确认 HTTP 服务本身是 PID 1，或者位于能转发信号的 init 后面。shell 包装脚本最后执行 exec，确保 SIGTERM 不会停在 shell 上。
服务在就绪前安装信号路径。原始 C 处理函数只设置 sigatomict 标志并向非阻塞 self-pipe 写入通知。日志、互斥锁、内存分配、数据库调用和子进程等待都留在处理函数之外。多线程实现中，我更倾向于在创建 worker 前阻塞终止信号，再由一个 sigwait 线程集中接收。两种方案都显式唤醒普通控制循环，不依赖 EINTR 恰好出现。
第一次 SIGTERM 原子地把服务从运行切换到停止接收，并设定 25 秒后的内部截止时间。服务立即让就绪探针失败，关闭或禁用新请求接收，阻止 keep-alive 连接继续发起请求，并停止拉取后台任务。端点摘除与应用接收边界都要做，因为就绪信息传播是异步的。
200 个已接收请求可以继续执行，数据库和缓存客户端此时保持可用。我直接跟踪这些请求。25 秒内完成的请求正常返回；到期后通过应用协议取消剩余请求并保留可重试状态。后台任务只有持久完成后才确认；未完成租约按队列契约释放或等待过期，副作用通过幂等键保护。
随后按约定信号终止两个子进程，并在限定时间内回收。请求与子进程都不再使用共享客户端后才关闭资源。日志和链路只获得很小且有上限的刷新预算。成功路径应在 30 秒内以零状态退出。错过截止时间后，SIGKILL 会直接终止进程，任何清理代码都不会执行，所以持久正确性不能依赖最后一个钩子。
验证时，我在真实镜像中维持 200 个不同耗时的并发请求和活跃租约任务，然后向容器发送 SIGTERM。我会断言实际进程收到信号、就绪状态失败、没有新工作越过接收边界、已接收工作在 25 秒内完成或明确取消、未完成任务能重试且副作用不重复、两个子进程都被回收，并且进程在 30 秒前退出。我还会测试重复 SIGTERM 的幂等性和 SIGKILL 下的恢复契约。滚动更新看板应展示退出耗时、进行中工作、截止时间违约和强制退出。”
常见错误
- 在原始处理函数里清理 → 信号可能在库锁或分配器状态被占用时打断程序 → 只发布最小的信号安全通知，在正常控制路径清理。
- 默认应用能收到
SIGTERM→ shell 形式入口可能让 shell 成为 PID 1 → 使用 exec 形式或以exec结束的包装脚本，并测试真实镜像。 - 把就绪失败当成已经停止接收 → 端点更新有延迟，直连和既有连接仍可能提交工作 → 同时让就绪失败，并执行应用级监听或接收截止。
- 先关闭共享客户端 → 已接收请求会在本来可以完成时失败 → 先排空使用者，再关闭它们依赖的资源。
- 不检查租约就停止任务消费者 → 任务可能长时间不可见、过早确认或重复产生副作用 → 明确执行确认、租约、重试和幂等契约。
- 为了完整排空无限等待 → 编排器最终发送
SIGKILL，所有清理机会都会消失 → 设置内部截止时间，并给收尾预留时间。 - 忘记管理子进程 → 子进程可能短暂存活，未回收时还会成为僵尸进程 → 明确转发终止信号，并用限时
waitpid回收。 - 重复信号重复启动清理 → 重复关闭和刷新可能竞争或崩溃 → 原子转换状态，并让清理幂等。
- 把标准信号当命令队列 → 相同待处理标准信号可能合并，也没有持久归属 → 任务与重试进入队列，信号只控制生命周期。
- 只测试内部退出接口 → 它绕过 PID 结构、运行时投递和编排行为 → 在真实并发工作下向生产镜像发送真实信号。
追问及应对
追问 1：为什么信号处理函数不能直接调用普通退出函数？
处理函数可能在当前线程或其他线程持有分配器、标准输入输出、日志或应用锁时打断程序。大多数应用清理函数不属于异步信号安全函数，直接调用会死锁或破坏内部状态。处理函数应设置标志并通过信号安全操作唤醒控制路径，随后由事件循环或专用信号线程调用普通退出代码。
追问 2：多线程进程中的信号如何投递？
信号处置方式由整个进程共享，每个线程有自己的信号掩码。发给进程的信号可以投递给任意符合条件且未阻塞该信号的线程。稳健做法之一，是在创建 worker 前阻塞终止信号，再由一个线程用 sigwait 或 signalfd 同步接收；另一种做法是使用只发布安全通知的最小处理函数。混乱的线程掩码会让行为难以推理。
追问 3：在这个场景中，SIGTERM 和 SIGKILL 的实际差别是什么？
SIGTERM 是终止请求，可以被应用捕获并触发退出协议；它的默认动作仍是终止进程。SIGKILL 由内核强制执行，不能捕获、阻塞或忽略，也不会运行清理。只有 SIGTERM 路径能到达、足够安全且有明确上限时，宽限期才真正有价值。
追问 4：为什么既要让就绪失败，又要关闭接收入口？
就绪变化通知 Kubernetes 及其代理停止路由，但端点更新和连接排空是异步过程，既有 keep-alive 或直连连接仍可能到达进程。应用接收截止点精确定义了何时起新工作不能进入；就绪失败负责把 Pod 移出正常路由。验证也应分别观察这两层。
追问 5：执行到一半的后台任务应该怎样处理？
遵循任务归属契约。只有能在内部截止时间前安全完成时才继续；否则停止或释放租约，使任务可重试，并且只在持久完成后确认。终止可能发生在外部副作用与任务确认之间，所以副作用需要幂等键或事务状态转换。
追问 6：存在 preStop 钩子时有什么变化？
钩子会消耗同一个 Pod 终止宽限期。应测量它的最坏耗时，并从应用预算中扣除。钩子需要有上限，也不要与应用退出流程重复执行两套相互竞争的清理。应用仍要正确处理 SIGTERM，因为钩子可能失败，进程也可能在正常滚动更新之外收到信号。
追问 7：如何调查生产中的强制终止？
把 Pod 终止原因和时间戳，与应用的退出开始时间、进行中数量、任务租约、子进程状态和最后完成的退出阶段关联起来。区分信号没有送达、排空过慢、子进程卡住和最终刷新阻塞。按版本监控优雅退出耗时与强制退出率，回归就能在灰度阶段被发现。