Ruby作业控制：SIGCONT处理器失效、SIGTSTP仅在IRB生效问题排查

AI 小北

2026-8-28

Ruby 终端作业控制实现问题排查

问题背景

我在基于Ruby-GNOME的GLib2 API为自定义事件循环处理器实现Shell作业控制功能时，预期通过处理SIGTSTP和SIGCONT信号，实现Shell运行环境下TTY进程的后台挂起、执行Shell fg命令后恢复后台进程的能力，但始终无法通过Ruby现有API梳理出完整的实现方案。

作为简化测试场景，我先尝试为IRB添加类似作业支持，在~/.irbrc中添加如下配置（执行IRB_JOBS_TEST=Defined irb即可激活测试逻辑）。测试中SIGTSTP处理器看似生效，但在BASH中执行fg发送SIGCONT后进程始终保持挂起状态：

## conditional section for  ~/.irbrc
## can be activated with `IRB_JOBS_TEST=Defined irb`
if ENV['IRB_JOBS_TEST']

  module Jobs
    TSTP_HDLR_ORIG ||= Signal.trap("TSTP") do
      STDERR.puts "\nJobs: backgrounding #{Process.pid} (#{TSTP_HDLR_ORIG.inspect}, #{CONT_HDLR_ORIG.inspect})"
      Process.setpgid(0, Process.ppid)
      TSTP_HDLR_ORIG.call if TSTP_HDLR_ORIG.respond_to?(:call)
    end

    CONT_HDLR_ORIG ||= Signal.trap("CONT") do
      Process.setpgid(0, Process.pid)

      STDERR.puts "Continuing in #{Process.pid}" ## not reached, not shown

      IRB.CurrentContext.thread.wakeup ## no effect

      CONT_HDLR_ORIG.call if CONT_HDLR_ORIG.respond_to?(:call)
    end
  end
end

测试环境为FreeBSD 13.1，已查阅FreeBSD系统中termios(4)、tcsetpgrp(3)、fcntl(2)的手册页，但不确定Ruby对终端相关系统API的封装覆盖程度。

测试中SIGTSTP处理器可被触发：按下Ctrl+z可将IRB进程切到Shell后台，但执行BASH的fg或%命令将进程切回前台后进程完全无响应，FreeBSD的Ctl-t状态查询显示进程处于挂起状态，自定义SIGCONT处理器内的逻辑完全未被执行。目前无法确定现有SIGTSTP处理器是否完成了将进程加入Shell后台进程组、释放控制终端的全部必要操作，也不清楚进程执行fg后仍保持挂起的根因。

在更复杂的GLib2测试场景中，仅调用如下代码无法实现进程后台化：

Process.setpgid(0, Process.ppid)

该场景示例代码较长暂不展开，因此优先以IRB作为测试切入点。将挂起进程切回前台后，在FreeBSD TTY下按下Ctrl-t查询到如下栈信息，显示进程恢复时似乎阻塞在ioctl调用上：

$ %                                                                                                        
IRB_JOBS_TEST=Defined irb                                                                                                           
load: 0.16  cmd: ruby31 4076 [suspended] 2.36r 0.19u 0.03s 1% 23828k             
mi_switch+0xc2 thread_suspend_check+0x260 sleepq_catch_signals+0x113 sleepq_wait_sig+0x9 _cv_wait_sig+0xec tty_wait_background+0x30d ttydev_ioctl+0x14b devfs_ioctl+0xc6 vn_ioctl+0x1a4 devfs_ioctl_f+0x1e kern_ioctl+0x25b sys_ioctl+0xf1 amd64_syscall+0x10c fast_syscall_common+0xf8

调试更新

经过数小时调试，移除GLib示例代码中的自定义SIGTSTP和SIGCONT信号处理器后，功能直接正常运行：非IRB环境下控制台运行的示例应用可正常切到后台，通过Shell将其切回前台进程组后可收到SIGCONT正常恢复，主事件循环日志无异常。

目前仍未明确IRB场景下自定义SIGTSTP/SIGCONT处理器的缺失逻辑，由于IRB自带输入历史记录，日常使用中直接重启进程即可解决问题。参考其他控制台应用的作业控制实现（例如Emacs主要在terminal.c中对TTY I/O流做封装处理），需要确认两个问题：

Ruby本身是否原生支持作业控制？
是否部分应用无需自定义信号处理器即可实现作业控制能力？

问题解答

故障根因

栈里出现的tty_wait_background已经直接点出问题：自定义信号处理器没有遵循TTY作业控制的标准时序，错误的进程组操作触发了内核的TTY后台进程访问保护，导致进程被内核二次挂起，根本轮不到执行自定义的SIGCONT处理逻辑。

标准Shell作业控制是Shell作为父进程主导的流程，测试代码里的SIGTSTP处理器逻辑有两个致命错误：

收到SIGTSTP时直接调用Process.setpgid(0, Process.ppid)把当前进程塞进Shell所在的进程组，打乱了Shell的作业跟踪逻辑。正常流程里，子进程收到SIGTSTP后应该先把信号处置重置为默认，给自己发SIGTSTP触发停止，Shell收到子进程停止的事件后，会自己调用tcsetpgrp()拿回终端控制权，再把停止的子进程加入后台作业列表。提前修改进程组，会导致Shell记录的作业状态和实际进程组状态不匹配。
SIGCONT处理器里只修改了进程自身的pgid，完全没有调用tcsetpgrp()把终端控制权交还给当前进程组。这种情况下只要进程尝试读写终端、调用终端相关ioctl，内核发现当前进程不属于终端前台进程组，会直接发送SIGTTIN/SIGTTOU信号把进程再次挂起，这就是进程一直阻塞在tty ioctl调用上、自定义SIGCONT逻辑完全不执行的直接原因。

核心问题明确答复

Ruby本身是否原生支持作业控制？
Ruby运行时完全继承Unix系统的默认作业控制行为，原生封装了进程组、信号、IO控制的基础系统调用接口，只是没有封装高层的作业控制逻辑。默认不对SIGTSTP/SIGCONT做自定义捕获时，内核和Shell的默认作业控制逻辑会完全正常运行，这就是删掉GLib示例里的自定义信号处理器后，功能直接恢复正常的原因。需要说明的是，Ruby标准库没有直接封装tcsetpgrp这类终端前台进程组设置接口，如果要手动实现完整的自定义作业控制流程，需要通过IO#ioctl传入对应termios请求号来调用。
是否部分应用无需自定义信号处理器即可实现作业控制能力？
是。所有不自定义捕获SIGTSTP/SIGCONT的控制台程序，不需要写任何额外代码，就能自动支持Ctrl+Z挂起、fg/bg调度恢复。只有需要在挂起/恢复时做自定义状态处理的程序——比如全屏TUI应用、带行编辑功能的CLI（需要恢复终端模式、重绘界面、重启IO监听）——才需要自定义信号处理器，且实现时必须严格遵循作业控制的标准时序，不能随意打乱Shell和内核协同的流程。

IRB场景的特殊说明

IRB依赖readline/libedit做行编辑，这类库本身已经内置了完整的作业控制信号处理逻辑：收到SIGTSTP时会先把终端重置为标准输入模式，再走标准停止流程；收到SIGCONT时会重新设置终端为raw编辑模式，重绘当前输入行、恢复编辑状态。在.irbrc里覆盖默认信号处理器时，不仅打乱了进程组操作时序，还破坏了readline内置的信号处理流程，自然会出现挂死问题。日常使用IRB不需要自定义这两个信号处理器，默认行为已经可以正常支持作业控制。

内容的提问来源于stack exchange，提问作者Sean Champ

Ruby作业控制：SIGCONT处理器失效、SIGTSTP仅在IRB生效问题排查

问题背景 #

调试更新 #

问题解答 #

故障根因 #

核心问题明确答复 #