docker容器中信号只能发送给pid 1进程，需通过主进程路由或init类工具（如tini）转发至目标子进程。
不能直接向容器内非 pid 1 的进程发送信号——docker 默认只将信号投递到容器主进程（即 pid 1），这是由容器运行时（如 runc）强制约定的。想让自定义信号抵达目标进程，必须借助“信号路由”逻辑，本质是让 pid 1 主进程接收后，再主动转发给子进程。
明确信号投递路径限制
Docker 容器的信号链路固定为：宿主机 → 容器运行时（runC）→ 容器 PID 1 进程。无论你用 kill -USR1 $container_pid 还是 docker kill -s SIGUSR1 $container_id，信号最终只会到达 PID 1。它不会自动广播或穿透到其他进程（比如你的 worker 进程、日志收集器等）。
这意味着：如果你的容器启动的是单个二进制（如 ./server），那它就是 PID 1，可直接处理；但若使用 supervisord、systemd 或 shell 启动多进程（如 sh -c "start-server & start-logger & wait"），则只有 shell 是 PID 1，它默认不转发信号——你需要自己实现路由逻辑。
用主进程做信号中继（推荐方案）
在 PID 1 进程中注册自定义信号处理器（如 SIGUSR1），解析信号意图，并调用 kill() 系统调用精准转发给目标子进程。关键点：
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 需维护子进程 PID 表（可通过
fork()记录，或扫描/proc/$pid/status获取子进程关系） - 避免硬编码 PID，建议子进程启动时向主进程注册（例如通过 Unix socket 或文件写入 PID）
- C 示例片段：
kill(target_pid, SIGUSR2);—— 主进程收到SIGUSR1后，主动向目标 PID 发送SIGUSR2
用 init 类进程替代 shell（简化运维）
用 tini（Docker 官方推荐）、s6-overlay 或 supervisord 替代默认 shell 启动方式。它们天然支持信号转发：
-
tini可配置-s参数，将接收到的信号广播给所有子进程（适合简单场景） -
s6-overlay支持 per-service 信号映射，例如把SIGUSR1转发给指定服务进程组 - 注意：
docker exec -it container kill -USR1 $pid仍无效——信号仍须从容器外发给 PID 1，再由 init 路由
绕过容器运行时的替代路径
若必须精确控制某子进程且无法修改主进程，可用以下间接方式：
-
docker exec $container_id kill -USR1 $target_pid：在容器命名空间内执行，绕过 runC 限制（前提是容器未禁用exec，且你已知目标 PID） - 通过共享内存 / 文件 / socket 通知主进程：“请向 PID X 发送信号 Y”，主进程再执行转发（更可控，适合复杂状态管理）
- 避免使用
kill -9或SIGKILL：它们不可捕获，无法被路由，只能终止进程本身
