CRIU项目中的进程信号处理机制解析：SIGSTOP与SIGTSTP差异

在进程检查点/恢复工具CRIU的使用过程中，开发者发现了一个与进程信号处理相关的技术细节：当尝试对通过Ctrl+Z（发送SIGTSTP信号）暂停的进程进行内存转储时，CRIU会报错退出，而使用SIGSTOP信号则能正常工作。这一现象揭示了Linux信号处理机制与CRIU实现之间的重要交互逻辑。

技术背景

Linux系统中有两个相似的暂停信号：

• SIGSTOP（信号值19）：不可捕获、不可忽略的强制暂停信号
• SIGTSTP（信号值20）：终端生成的交互式暂停信号（通常由Ctrl+Z触发）

虽然两者都能暂停进程执行，但CRIU在3.18版本之前仅支持处理被SIGSTOP暂停的进程。这是因为CRIU的内部机制需要精确控制进程状态，而SIGTSTP允许进程安装自定义信号处理器，增加了状态捕获的复杂性。

问题本质

当用户尝试对SIGTSTP暂停的进程执行CRIU转储时，会遇到以下错误：

Error: SEIZE pid: unsupported stop signal 20

这表明CRIU的进程捕获(infect)模块在3.18版本前没有完整实现SIGTSTP信号的处理逻辑。该限制源于：

1. 信号处理语义差异：SIGTSTP允许进程捕获并执行清理操作
2. 状态一致性要求：CRIU需要确保进程处于完全静止状态
3. 恢复复杂性：自定义信号处理器可能影响恢复后的行为

解决方案演进

CRIU社区在3.18版本中通过提交c7858ba42修复了此问题，该提交：

1. 扩展了信号处理支持范围
2. 完善了进程状态捕获逻辑
3. 确保了对交互式暂停进程的兼容性

对于仍在使用旧版本的用户，建议的替代方案是：

• 使用kill -STOP pid替代Ctrl+Z
• 升级到CRIU 3.18及以上版本

实践建议

在需要同时生成核心转储和CRIU检查点的场景中，推荐采用以下流程：

1. 使用SIGSTOP暂停目标进程（确保完全静止）
2. 生成核心转储文件
3. 执行CRIU内存转储
4. 根据需求决定是否继续进程执行

这种顺序操作可以保证两个快照的一致性，避免进程状态在转储间隙发生变化。理解这些底层机制有助于开发者更好地设计基于CRIU的容错和迁移方案。