VPS 重启后服务没起来怎么办？AI Agent 自动检查 systemd 服务状态

VPS 重启后服务没起来是运维老生常谈的问题，主机选发现很多故障其实是依赖没拉起或者 systemd 配置没写对。手动排查费时费力，利用 AI Agent 自动检查 systemd 服务状态，能快速定位是 Docker 没起还是端口被占用，甚至能尝试自动修复。这套方案适合部署了 n8n、Ollama 等复杂环境的服务器，能大幅降低人工巡检成本。

VPS 重启服务异常的常见原因

服务起不来通常不是系统坏了，而是配置没考虑到重启场景。很多新手在 Docker 部署 AI 工具时，只顾着跑通容器，忘了配置开机自启，或者忽略了服务之间的启动顺序。

Docker 容器启动策略缺失

大多数 AI Agent 或 Web 服务都跑在 Docker 里。如果创建容器时没加 `–restart=always`，或者 docker-compose 里没写 `restart: unless-stopped`，VPS 一重启，容器就停在那儿了。更坑的是，如果宿主机 Docker 服务本身没设为开机自启，那容器策略写得再好也没用。

网络依赖与启动时序冲突

有些强依赖网络的 AI 工具（如调用外部 API 的 Agent），在系统刚起来网络还没通时就启动了，导致报错退出。systemd 的 `After=network.target` 只能保证网络服务启动，不能保证网络已连通。这类服务启动失败后，如果没有重启策略，就会一直挂起。

编写服务状态巡检脚本

要让 AI Agent 懂发生了什么，得先有个脚本去收集现状。这个脚本负责把当前系统状态翻译成 AI 能读懂的文本。

systemctl 命令与日志提取

写个 Bash 脚本，检查关键服务状态。不要只看 `running`，要看 `failed`。

#!/bin/bash
services=("docker" "nginx" "ollama")

status_report="System Status Check:\n"

for service in "${services[@]}"; do
if systemctl is-active –quiet "$service"; then
status_report+="[$service] OK\n"
else
status_report+="[$service] FAILED\n"
logs=$(journalctl -u "$service" -n 20 –no-pager)
status_report+="Logs:\n$logs\n"
fi
done

echo -e "$status_report"

把这段脚本保存为 `/usr/local/bin/check_services.sh`，记得给执行权限 `chmod +x /usr/local/bin/check_services.sh`。

数据格式化以便 AI 读取

AI Agent 处理结构化数据比处理乱七八糟的日志强。上面的脚本只是第一步。如果你接的是 Claude Code 或 GPT-4，可以把输出格式化成 JSON，或者直接把报错信息提取出来。重点是别把几千行的无用日志丢给 AI，它处理不了那么长的上下文，还会浪费 Token。

接入 AI Agent 进行智能诊断

拿到状态报告后，就是 AI Agent 发挥作用的时候了。这里有两种思路：一是本地跑个轻量级模型（如通过 Ollama 跑 Llama3）分析，二是调用 API 发给 n8n 或其他 Agent 平台。

使用本地 LLM 分析日志报错

如果你的 VPS 资源够用，本地部署 Ollama 最安全，日志不出服务器。写个简单的 Python 脚本，把上面的 `status_report` 喂给本地模型。

curl http://localhost:11434/api/generate -d '{
"model": "llama3",
"prompt": "分析以下系统服务状态报错，给出修复建议：\n'"$(bash /usr/local/bin/check_services.sh)"'",
"stream": false
}'

这样 AI 就能告诉你“端口被占用”、“配置文件路径错误”或者“内存不足”等具体原因，而不是只给你一个“服务挂了”的结论。

n8n 工作流与自动修复尝试

对于生产环境，建议用 n8n 接管。在 VPS 上设置一个 Cron，每 5 分钟跑一次检查脚本。如果发现 `FAILED`，就触发 n8n 的 Webhook。

n8n 节点设计思路：
1.Webhook：接收服务名和错误日志。
2.AI Agent 节点：分析日志，判断是重启能解决还是需要人工介入。
3.HTTP Request 节点：如果是简单错误（如进程假死），发送 API 给服务器执行 `systemctl restart service_name`。

注意：千万别让 AI 有权限直接 `rm -rf` 任何东西，只给它重启服务的权限。

部署自动化监控服务

脚本有了，AI 也有了，怎么让它们在 VPS 重启后自动跑起来？还是得靠 systemd。

配置 systemd 定时器

不要用 root 的 crontab，用 systemd timer 更专业，还能记录日志。

创建服务文件 `/etc/systemd/system/service-monitor.service`：

ini
[Unit]
Description=Check Services and Notify AI Agent
After=network.target

[Service]
Type=oneshot
User=root # 建议新建一个低权限用户运行
ExecStart=/usr/local/bin/check_services.sh | /usr/local/bin/notify_ai_agent.sh

创建定时器 `/etc/systemd/system/service-monitor.timer`：

ini
[Unit]
Description=Run Service Monitor every 5 mins

[Timer]
OnBootSec=3min # 启动 3 分钟后开始跑，给系统一点缓冲时间
OnUnitActiveSec=5min
Unit=service-monitor.service

[Install]
WantedBy=timers.target

启用并启动：

systemctl enable service-monitor.timer
systemctl start service-monitor.timer

避免无限重启的熔断机制

如果服务一直起不来，AI Agent 一直尝试重启，会导致 VPS 负载飙升。在脚本里加个计数器，或者利用 systemd 的 `StartLimitIntervalSec` 和 `StartLimitBurst`。

在服务文件里加：
ini
[Service]
StartLimitIntervalSec=60
StartLimitBurst=3 # 60 秒内只允许重启 3 次

这样能防止死循环把机器搞死。

老鸟叮嘱

1.别把所有日志都丢给 AI：只截取报错前后的 20-50 行，上下文太长不仅费钱，AI 还容易胡说八道。
2.API Key 别硬编码：如果用 n8n 或 OpenAI API，Key 必须放在环境变量或密钥管理工具里，严禁写在脚本里。
3.测试故障场景：部署完别光看跑没跑，手动停掉一个 Docker 容器，看 AI Agent 能不能在 5 分钟内发现并报警。
4.区分“没起来”和“正在起”：有些大模型（如本地跑的 70B 参数模型）启动要一两分钟，检查脚本要设个超时时间，别把“正在启动”误判为“启动失败”。

FAQ

VPS 重启后 Docker 服务起不来怎么办？
先检查 `systemctl status docker`，通常是因为磁盘空间满了或者 overlay2 存储驱动出错。运行 `docker system prune -a` 清理一下未使用的镜像和容器通常能解决。

AI Agent 能自动修复所有服务故障吗？
不能。AI 擅长分析日志和执行预设的修复命令（如重启服务、修改配置），但遇到硬件故障或严重的依赖冲突，它只能报警，不能瞎修，否则越修越乱。

为什么我的 systemd 服务一直显示 Activating？
通常是 `Type=notify` 配置错误，或者服务主进程卡住了。检查服务日志 `journalctl -u 服务名 -f`，看是不是卡在加载数据库或连接外网。

低配置 VPS 能跑本地 AI Agent 做监控吗？
不建议。跑监控脚本占用很低，但如果本地跑 LLM（如 Llama3）分析日志，至少需要 4GB 以上内存。低配机器建议用 n8n 调用云端 API 的方式。

VPS 重启后服务没起来确实让人头大，但通过 systemd 配合 AI Agent 的自动化检查，大部分依赖问题和启动故障都能在几分钟内被发现甚至自动修复。核心在于写好检查脚本，给 AI 提供精准的上下文，并限制好自动修复的权限范围。这套方案不仅能救火，还能在日常运维中帮你积累大量故障处理经验。