为什么bash中执行jobs命令会返回已终止进程的PID？

调试bash后台任务管理逻辑时，出现非预期行为：所有后台子任务全部正常执行完毕退出后，jobs -p仍会返回单个已退出的进程PID，直接对该PID执行kill命令时会提示"No such process"。 #

#!/bin/bash
set -e

function start_job {
    echo "Kicking off job that sleeps for ${1}"
    sleep "${1}" && echo "Slept for ${1}!" &
}

# Start some jobs - print current child pids.
echo "Jobs are: $(jobs -p)"
start_job 5
echo "Jobs are: $(jobs -p)"
start_job 6
echo "Jobs are: $(jobs -p)"
start_job 7
echo "Jobs are: $(jobs -p)"

# Wait long enough for all children to finish.
echo "Main thread sleeping for 10 and killing all remaining jobs."
sleep 10
echo "Killing sub-jobs."
echo "Jobs are: $(jobs -p)"
kill $(jobs -p)

• 若将脚本末尾主程序的休眠时长调整为5秒，可正确识别尚未运行结束的2个任务PID，终止操作正常执行
• 若保持默认10秒主休眠时长（预留足够时间让所有子任务执行完成），运行输出如下：

Jobs are: 
Kicking off job that sleeps for 5
Jobs are: 3352412
Kicking off job that sleeps for 6
Jobs are: 3352412
3352415
Kicking off job that sleeps for 7
Jobs are: 3352412
3352415
3352418
Main thread sleeping for 10 and killing all remaining jobs.
Slept for 5!
Slept for 6!
Slept for 7!
Killing sub-jobs.
Jobs are: 3352418
./mini_job_test.sh: line 23: kill: (3352418) - No such process

对照测试验证：

• 加-r参数筛选运行态任务时，jobs -pr返回空列表，不会输出无效PID
• 加-s参数筛选已停止任务时，jobs -ps同样返回空列表
• 不带筛选参数的jobs -p，才会输出这个已经不存在的进程PID

这是bash作业控制逻辑的固有行为，核心原因有两层：

1. bash的作业表状态分类规则
   bash的作业表会记录三类状态的后台作业：运行中、已停止、已终止待清理。其中已终止待清理的作业，是指进程已经正常退出、但bash还未将其元数据从作业表中完全清除的条目。
   这类已终止的作业条目，既不属于运行态（-r筛选条件）也不属于停止态（-s筛选条件），因此用jobs -pr或jobs -ps都不会匹配到，但默认的jobs -p会列出作业表中所有条目，包括这类待清理的已终止作业。
2. 作业表的清理时机规则
   bash只会在前台进程控制权交回shell时，才会触发作业表的状态同步：
   • 对于较早退出的5s、6s任务，在退出后bash会在后续的信号处理流程中，将它们的完成提示打印出来，并把对应的作业条目从作业表中移除
   • 对于最后退出的7s任务，当主程序的sleep 10执行完毕、控制权刚交回bash时，这个刚退出的作业条目还停留在待清理的缓存区，没有被同步清除，因此会被jobs -p捕捉到
     此时这个条目对应的PID，已经在系统层面随进程退出被回收了，因此执行kill时会提示进程不存在。

• 若需要获取当前仍然存活的后台任务PID，直接使用jobs -pr筛选运行态任务，可自动避开已终止的残留条目
• 若需要在执行kill操作前清空作业表的残留条目，可在调用jobs前先执行一次内置命令（如true），主动触发bash的作业表同步清理流程

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