SIGSTOP和SIGCONT不可捕获或忽略，是内核强制规定的控制信号，用于可靠暂停（TASK_STOPPED）和恢复进程执行；其“处理”在于正确发送（kill -STOP/CONT）与状态响应，而非注册信号处理器。
Linux中处理 SIGSTOP 和 SIGCONT 的核心在于：它们是不可捕获、不可忽略的控制信号，专用于进程执行状态的切换——暂停与恢复。关键不在于“怎么注册处理函数”，而在于“怎么正确发送和响应”。
为什么不能写 signal() 或 sigaction() 来处理它们
SIGSTOP（编号19）和 SIGCONT（编号18）被内核硬性规定为不可捕获、不可忽略。无论你在代码里调用 signal(SIGSTOP, handler) 还是 sigaction() 设置自定义行为，系统都会直接忽略。这是设计使然，目的是保证进程能被可靠地暂停和唤醒，避免调试或作业控制失效。
所以，真正的“处理”不是编程层面的拦截，而是理解其触发方式和状态表现：
- SIGSTOP 一发，进程立刻进入 TASK_STOPPED 状态，所有执行冻结，CPU 时间片被剥夺；
- SIGCONT 一发，只要进程处于 STOPPED 状态，就会立即回到 RUNNING 或 INTERRUPTIBLE 状态，继续从暂停点执行；
- 进程在 STOPPED 状态下仍保有全部内存、打开的文件描述符、信号队列等资源，只是不调度；
- 用
ps或top查看时，状态列为 T（如ps -o pid,stat,comm），表示已暂停。
实际中怎么挂起和恢复进程
分两种常见场景操作：
-
前台进程：按
Ctrl+Z，Shell 自动发送SIGTSTP（可被捕获，但默认行为同 SIGSTOP）；之后用fg恢复前台运行（发 SIGCONT），bg放入后台运行（也发 SIGCONT）； -
任意进程（含后台/守护进程）：先用
ps或pgrep找到 PID，再执行：kill -STOP（等价于kill -19）kill -CONT（等价于kill -18）
需要注意的几个细节
这些信号看似简单，但容易踩坑：
- 对已终止或僵尸（Z）状态的进程发 SIGCONT 无效，会返回
ESRCH错误； - 对正在执行
exec或刚 fork 但尚未 exec 的子进程发 SIGSTOP，可能因竞争导致状态不稳定； - 若进程在系统调用中被阻塞（如 read 等待输入），收到 SIGSTOP 后会先退出系统调用再暂停，不会卡死；
- 恢复后，进程继续执行原指令流，包括未完成的系统调用——比如被暂停前正在
sleep(10)，恢复后会继续睡完剩余时间。
程序里主动控制子进程的例子
像知识库中 C 示例那样，父进程用 fork() 创建子进程后，通过 kill(pid, SIGSTOP) 和 kill(pid, SIGCONT) 控制其生命周期，是完全可行且安全的做法。注意两点：
- 务必检查
kill()返回值，失败可能是目标进程已退出或权限不足； - 暂停后不要立即尝试读写子进程的共享资源（如管道），需确保它确实已停稳（可用
waitpid(pid, &status, WUNTRACED)等待 STOPPED 状态确认）。
