守护进程导致程序kill掉后被重新拉起

ps aux | grep "supervisord"

从上面的命令可以查找到守护进程的配置文件位置：

/etc/supervisor/supervisord.conf

从配置信息看，守护进程的配置文件，又加载了/etc/supervisor/conf.d/*.conf的所有相关配置信息；

cat /etc/supervisor/conf.d/* | grep "postgrest"

cat /etc/supervisor/conf.d/* | grep "postgrest"

查询结果为空；说明不是守护进程拉起的；

查询父进程：

pstree -aps 4127561

根据你提供的 pstree -aps 4127561 输出结果，结合进程树分析原理，以下是完整的进程层级解析：

🌳 进程树结构分析

graph TD
    A[systemd,1] --> B[containerd-shim,4127532]
    B --> C[postgrest,4127561]
    C --> D1({postgrest线程})
    C --> D2({...24个子线程})

1. ​​顶层进程：systemd (PID 1)​​

• 作为所有进程的根父进程，负责系统初始化和管理服务生命周期
• 启动参数：--system --deserialize 85 表示以系统模式启动并反序列化状态数据

2. ​​容器运行时层：containerd-shim (PID 4127532)​​

• 关键参数解析：
  • -namespace moby：使用 Docker 的默认命名空间（Moby 是 Docker 的开源组件）
  • -id7f3bb...：容器唯一 ID，对应 Docker 容器实例
• 作用：作为容器引擎 containerd 的子进程，负责管理容器内进程的生命周期和资源隔离

3. ​​目标进程：postgrest (PID 4127561)​​

• ​​进程特征​​：
  • 由 containerd-shim 直接拉起，表明运行在 Docker 容器环境中
  • 包含 ​​24个工作线程​​（如 {postgrest},4127721 至 4127745），这是 PostgREST 的典型多线程架构
• ​​异常状态验证​​：
  若此前发现 /bin/postgrest 文件不存在但进程仍在运行，说明可执行文件已被删除（常见于容器更新或文件误删），但进程因未重启而持续占用内存

---

⚠️ 关键结论与建议

1. ​​进程来源​​
   PostgREST 进程由 ​​Docker 容器​​（通过 containerd-shim 管理）启动，非 Systemd 或 Cron 直接调用。

2. ​​线程资源占用​​
   24个工作线程表明服务处于高负载状态，需检查：

   top -p 4127561  # 实时监控该进程的CPU/内存
   cat /proc/4127561/status | grep Threads  # 确认线程数

3. ​​容器管理建议​​

   • 重启容器以恢复缺失的可执行文件：

     docker ps -q | xargs docker inspect | grep 7f3bb446a666  # 根据ID查找容器
     docker restart <容器名>

   • 若需彻底清理：

     docker rm -f <容器名> && docker run -d --name postgrest postgrest/postgrest

通过此进程树可确认：​​PostgREST 是容器化部署的服务​​，任何文件变动需通过容器操作而非直接修改宿主机文件。