Linux 服务显示 active (exited) 却没有常驻进程：一次性任务与常驻 worker 怎么区分

部署脚本最后一行是绿色的，服务状态命令也显示 active (exited)，但用 ps 却找不到名为 queue-worker 的常驻进程。这个现象不一定是服务管理器失灵，更多时候是 unit 文件把“一次性动作完成”误判成了“服务应该持续运行”的信号。

状态本身不是异常报错，它只是说明服务管理器已经判定该单元的动作成功走完，但对应的主进程已经正常退出，绝大多数场景下都不是管理器本身故障，而是配置和预期的进程生命周期不匹配。

看到 active (exited)，先别急着重启

现场通常来自一个看似成功的发布检查：服务单元没有报红，日志里也有“启动完成”的输出，可是端口没有监听，队列消费者也没有拉取新任务。此时连续重启只会重复同一套行为，先把括号里的 exited 看清楚更重要。

服务状态命令展示的是 unit 的状态，不是“某个同名进程一定存在”的承诺。对 Type=oneshot 来说，主进程成功返回后，服务管理器可以把这次动作记为完成；如果 unit 还设置了 RemainAfterExit=yes，它甚至会继续显示为 active。

[Unit]
Description=Prepare report directory

[Service]
Type=oneshot
启动命令=/usr/local/bin/prepare-report-dir
RemainAfterExit=yes

上面的 unit 适合“准备文件夹”这种动作。命令跑完后没有服务进程是正常结果，active (exited) 说明准备动作完成，而不是说明一个 worker 仍在后台工作。

Type=oneshot 到底改变了什么

服务管理器要先判断 unit 的启动方式，再决定什么时候算启动完成。一次性服务的重点是等待启动命令结束：返回码为 0，动作就成功；返回非 0，unit 才会进入失败状态。

因此，下面这个检查结果不能单独证明 worker 正常：

svcctl is-active queue-worker
# active

svcctl show queue-worker -p Type -p MainPID -p SubState
# Type=oneshot
# MainPID=0
# SubState=exited

MainPID=0 和 SubState=exited 已经给出了关键线索。命令成功退出、状态被保留，与一个正在监听端口的进程是两件完全独立的事。

最容易误判的三个配置点

把脚本放进启动命令就以为它会常驻

脚本是否常驻由脚本自身逻辑决定，unit 的名字不会改变它的运行行为。如果脚本做完一次同步就退出，服务管理器看到的就是一次性动作。需要持续运行时，应该让被管理的程序本身保持前台运行，并让 unit 类型与它的行为一致。

把 RemainAfterExit 当成后台保活

RemainAfterExit=yes 的作用是保留激活状态，方便其他 unit 依赖“初始化已经完成”这个结果。它不会重新拉起进程，也不会监控一个已经退出的 PID。把它加到 worker unit 上，只会让状态看起来更容易被误读。

只看绿色状态，不看端口和业务证据

对于 HTTP 服务，至少要核对监听端口；对于队列消费者，至少要核对进程树、最近日志和消费指标。服务状态命令是入口，不是完整验收。

让服务状态和真实进程对齐

如果目标确实是常驻 worker，可以把 unit 改成前台运行的服务。下面的示例省略了用户、文件夹和环境变量等项目差异，只保留状态判断所需的骨架：

[Unit]
Description=Report queue worker
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
启动命令=/usr/local/bin/queue-worker --config /etc/queue-worker/config.yaml
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

修改后依次重载 unit、启动服务，再查询服务管理器看到的主 PID：

svcctl daemon-reload
svcctl restart queue-worker
svcctl show queue-worker -p Type -p MainPID -p SubState
# 将上一条命令输出的 MainPID 替换到这里
ps -fp 2418

这里别只追求 active (running) 这一行。若 MainPID 有值但进程马上退出，状态会转为 failed；若进程活着却没有监听端口，还要继续检查参数、配置文件和权限。状态、进程、端口三者都对得上，才算完成这一轮修复。

前置初始化和常驻服务应该怎么拆

一个常见的正确结构是：初始化动作单独作为 queue-prepare.service，worker 单独作为 queue-worker.service。前者可以是 oneshot，后者保持前台运行；不要让一个 unit 同时承担两种生命周期。

# queue-worker.service
[Unit]
Requires=queue-prepare.service
After=queue-prepare.service

[Service]
Type=simple
启动命令=/usr/local/bin/queue-worker --config /etc/queue-worker/config.yaml
Restart=on-failure

这种拆分让故障更容易定位：准备动作失败，看 report-prepare.service 的日志；worker 退出，看自己的重启计数和退出原因；不要通过一个永远 active 的 oneshot 状态掩盖真正的进程生命周期。

复测时用三条证据收口

修完后建议保存一次完整输出，方便发布记录和下次排查对照：

1. 状态证据：svcctl is-active queue-worker 返回 active，并且 SubState=running。
2. 进程证据：MainPID 对应的进程仍存在，命令行参数与 unit 中的启动命令一致。
3. 业务证据：端口、健康检查或队列消费指标出现预期变化。

如果只需要确认初始化任务是否完成，active (exited) 反而是合适的结果；如果需要守护一个长期运行的程序，就必须把验收目标换成 active (running) 加上真实业务证据。

相关问题

active (exited) 一定是配置错误吗？

不一定。文件夹初始化、缓存预热、数据库迁移等一次性动作正常结束后，显示这个状态很常见。只有当 unit 的目标是常驻服务时，它才是值得排查的信号。

Type=oneshot 可以配置 Restart 吗？

需要谨慎核对服务管理器版本和 unit 目标。更稳妥的做法是把失败重试策略放在一次性任务自身或调度层，并确保不会重复执行不可幂等的迁移动作。

为什么 ps 看不到服务名，但服务仍然在工作？

进程名可能来自二进制文件、解释器或启动脚本，不一定等于 unit 名。应使用 MainPID 获取 PID，再结合命令行、子进程和监听端口判断。

改完 unit 文件后为什么状态没变化？

服务管理器需要重新读取 unit 文件。先运行 svcctl daemon-reload，再按需要重启服务；如果 unit 被模板、覆盖目录或生成配置替换，还要用 svcctl cat queue-worker 查看最终内容。

最后的判断

看到 active (exited) 时，先问 unit 的任务是“做完就结束”，还是“启动后一直工作”。前者用 oneshot 并保留完成状态很合理；后者应让程序前台常驻，使用运行态检查、PID 检查和业务检查共同验收。把这两个生命周期拆开，服务管理器的状态就不会再和现场互相矛盾。