Linux 服务重启后如何确认真的恢复：从进程到业务的四层检查

服务重启成功不等于业务恢复。systemctl restart 返回 0，只能说明 systemd 接受了操作；进程可能随后崩溃，端口可能监听了但接口仍然报错，后台任务也可能还没有恢复。

下面是一套适合日常排障的四层检查顺序：服务状态、进程、端口、业务响应。每一层解决的问题不同，少一层就可能得到假阳性。

第一层：看 systemd 状态

systemctl is-active myapp.service
systemctl status myapp.service --no-pager -l
journalctl -u myapp.service -n 80 --no-pager

is-active 返回 active 只能说明主进程当前还在。重点看最近一段日志里有没有启动后立刻退出、端口绑定失败、配置解析失败等信息。

如果服务是 Type=oneshot，状态显示 inactive 可能是正常的，应该改看最近一次的退出码：

systemctl show myapp.service -p ExecMainStatus -p Result

第二层：确认进程和命令行

pgrep -af 'myapp|server.py'
ps -o pid,ppid,etime,%cpu,%mem,args -p <PID>

同一个服务可能残留旧进程，也可能启动了错误的配置文件。把完整命令行打印出来，能快速发现工作目录、配置路径和环境变量是否正确。

如果服务由 supervisor、Docker 或 systemd 多层管理，先确认到底是哪一层负责重启，避免手动启动出第二份实例。

第三层：确认端口和监听地址

ss -lntp | grep ':8080'
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/health

端口存在只能说明某个进程在监听。还要检查监听地址：绑定 127.0.0.1 只能本机访问，绑定 0.0.0.0 才能接受外部连接。反向代理场景还要分别检查代理端口和后端端口。

第四层：做一次真实业务请求

健康检查最好分成两类：

存活检查只确认进程还活着：

GET /health

就绪检查确认依赖已经准备好：

GET /ready

数据库、缓存、消息队列还没连接完成时，进程可能已经监听端口，但服务其实还不能处理请求。生产环境应该让负载均衡器使用 readiness 检查，而不是只检查 TCP 端口。

如果服务没有健康接口，至少调用一个只读业务接口，并检查状态码、响应结构和关键字段：

curl -fsS http://127.0.0.1:8080/api/version | python3 -m json.tool

常见的四种假恢复

服务 active，但进程不断重启。

systemd 可能在重启策略下不断拉起进程，短时间内 status 看起来正常。查看 NRestarts 和日志时间线：

systemctl show myapp.service -p NRestarts -p ActiveEnterTimestamp

端口监听，但请求全部 502。

这通常是反向代理能连到端口，却拿不到有效响应。检查后端日志、代理 upstream 配置和协议是否一致。

接口返回 200，但业务数据是空的。

应用启动了，但数据库连接到了错误的实例，或者迁移没有完成。健康检查不能只看状态码，还要验证响应中的版本、租户或数据源标识。

本机正常，外部访问失败。

依次检查监听地址、防火墙、安全组、反向代理和 DNS。不要因为 curl 127.0.0.1 成功就判断公网服务正常。

一个简单的检查脚本

#!/usr/bin/env bash
set -u

service="$1"
url="${2:-http://127.0.0.1:8080/health}"

printf '服务状态: '
systemctl is-active --quiet "$service" && echo OK || echo FAIL

printf '监听端口: '
ss -lntp | grep -q ':8080' && echo OK || echo FAIL

printf '业务响应: '
code=$(curl -sS -o /dev/null -w '%{http_code}' --max-time 5 "$url" || true)
[ "$code" = 200 ] && echo "OK ($code)" || echo "FAIL ($code)"

把检查脚本放进部署流程或发布后的验证步骤里，比只执行一次 systemctl restart 更可靠。服务恢复的判断应该落到用户真正能访问和使用的结果上。