Documentation
¶
Overview ¶
Package runnerproc 判定某个安装目录下的 actions/runner 进程是否存活。
为什么不读 pid 文件：actions/runner 根本不写。三个启动脚本 （src/Misc/layoutroot/run.sh、src/Misc/layoutroot/run-helper.sh.template、 src/Misc/layoutbin/runsvc.sh）里都没有落 pid 文件的语句，pid 只存在 shell 变量 $PID 里；安装目录下的 .path 装的是 PATH 字符串，不是 pid——runsvc.sh 里就写着 `export PATH=$(cat .path)`。
早先按 "Runner.Listener.pid" / ".path" 读 pid 的做法因此对任何一个真实的 runner 目录都恒为「未找到」，于是每个 runner 都被判定为未运行，被 Manager 的定时巡检每 5 分钟重复拉起一次。
改为扫 procfs、按 argv 里的绝对路径认领进程。扫描本身由 procfind-kit 负责， 本包只留 actions/runner 特有的那部分知识：哪些脚本、哪个可执行文件， 以及为什么两者都得认（见 runnerSpec）。
只在有 procfs 的系统（Linux）上有效；其余平台一律返回「找不到」， 与修复前的实际行为一致（那时 pid 文件同样永远不存在）。
Index ¶
Constants ¶
const ShutdownReserve = 5 * time.Second
ShutdownReserve 是 PID 1 在宽限期里留给自己的余量：关 HTTP 服务、写完最后一行日志。 不留这一段，它会一直等到 docker stop 的计时器走完，然后连自己都是被 SIGKILL 的， 「runner 还没退出」这行日志也就永远打不出来——而那正是排查时唯一的线索。
const StopGracePeriod = 30 * time.Second
StopGracePeriod 是 docker stop 给容器的宽限期：Manager 停 Runner 容器时的 -t 参数， 也是 docker-compose.yml 里 runner-manager 的 stop_grace_period。
收到 SIGTERM 的那个 PID 1（容器模式下是 Agent，默认模式下是 Manager）最多等 StopGracePeriod - ShutdownReserve 让 Runner 退出，余下的留给自己收尾。 这几处必须一起改，所以宽限期只在这里定义一次：两边一旦不一致，短的那边说话—— -t 比 Agent 等的时间短，Agent 还在等 Runner，容器就整个被 SIGKILL 了。
Variables ¶
This section is empty.
Functions ¶
func FindMany ¶
FindMany 一次扫描 procfs，把进程分派给各自的安装目录，结果按传入的原字符串索引。 与逐个调用 Find 等价，区别只在于 N 个目录也只扫一遍——List 要同时判定一整批 runner，逐个扫等于把整张进程表读 N 遍。
func ListenerBinary ¶
ListenerBinary 返回该安装目录下 Runner.Listener 可执行文件的绝对路径。
Types ¶
This section is empty.
Source Files