为何service_test & kill -s SIGUSR1 $!无法启动后台进程？

你的猜测完全正确——问题核心就是发送SIGUSR1信号时，后台进程里的trap还没完成定义。

具体原因： #

• 执行service_test &时，Bash会fork子进程运行该函数，但子进程的初始化（包括加载函数代码、设置trap信号处理）需要时间，而主进程会立刻执行下一条kill -s SIGUSR1 $!命令。
• 默认情况下，SIGUSR1的系统默认处理行为是终止进程。如果此时子进程还没来得及设置trap覆盖默认行为，收到信号就会直接被杀死，看起来就像“无法启动”。
• 加sleep 1能解决问题，是因为这段时间足够子进程完成初始化，trap已经生效，此时收到SIGUSR1会执行你定义的处理逻辑，而非终止进程。

更可靠的解决办法（替代sleep）： #

sleep属于“依赖环境延迟”的方案，不同场景下需要的等待时间不确定，更严谨的方式是让后台进程主动通知主进程它已准备好：

• 文件同步法：后台进程完成trap设置后创建临时标记文件，主进程循环检查文件是否存在再发信号：

  service_test() {
      # 先设置信号处理
      trap 'echo "Received SIGUSR1"' SIGUSR1
      # 创建就绪标记
      touch /tmp/service_ready
      # 后续业务逻辑
      while true; do sleep 0.1; done
  }
  
  # 启动后台进程
  service_test &
  PID=$!
  
  # 等待就绪标记出现
  while [ ! -f /tmp/service_ready ]; do
      sleep 0.01
  done
  
  # 发送信号
  kill -s SIGUSR1 $PID
  # 清理临时文件
  rm /tmp/service_ready
  

• 管道同步法：用匿名管道传递就绪信号，避免临时文件的清理问题：

  # 创建匿名管道
  exec 3<> /tmp/fd3
  
  service_test() {
      trap 'echo "Received SIGUSR1"' SIGUSR1
      # 向管道写入就绪信号
      echo 1 >&3
      while true; do sleep 0.1; done
  }
  
  service_test &
  PID=$!
  
  # 阻塞等待就绪信号
  read -u 3
  
  kill -s SIGUSR1 $PID
  # 关闭管道
  exec 3>&-
  

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