第一次发现 OpenClaw 没有跟着 ZimaBoard 一起复活，是在一个普通的工作日早上。头天晚上小区变压器检修，家里停了半小时电，ZimaBoard 这种低功耗板子有电就自动开机，所以我默认一切正常。结果 SSH 进去一看，端口没有监听，OpenClaw 静悄悄地躺在那儿，等于整个早上对外服务都是断的。从那一刻起我就决定，不能再把“手动 systemctl start”当成本能，得让这台机器学会自己恢复。这篇就来聊聊我从硬件、系统到应用三层做下的开机自启与断电自动恢复改造，适合所有把 OpenClaw 或其他常驻服务跑在迷你主机上的朋友参考。
1. 为什么选 ZimaBoard 给 OpenClaw 当“长跑底座”
1.1 OpenClaw 这类服务需要什么样的运行环境
OpenClaw 是典型的常驻型自托管服务，它的特点是内存占用不大但进程必须一直在：白天要响应调用，凌晨可能还在跑定时任务。所以它比普通脚本更吃“系统稳定性”。部署 OpenClaw 的机器要满足三个条件：第一，24 小时开机的电费足够低；第二，系统掉电后有自动恢复能力而不只是手动重启；第三，有足够的磁盘和网络吞吐来存放日志与响应数据。
我最初也考虑过把它放在云主机上，但自托管服务的意义就是数据尽量在自己手里。常驻运行需要稳定的网络出口和定时任务能力，放在本地更符合预期。这样对宿主机的要求就变成了：功耗低、x86 架构（兼容性最好）、能装主流 Linux、并且硬件层面支持来电自启。这几个条件放到一起，ZimaBoard 就变得非常顺眼。
1.2 ZimaBoard 的硬件底子
ZimaBoard 是一块 x86 单板服务器，板载 Intel 处理器，自带 SATA 口、PCIe 插槽和双千兆网口，可以插 NVMe 或 2.5 寸 SSD，运行 Debian、Ubuntu 这类系统没有任何兼容压力。它的功耗通常在十几瓦以内，比一台闲置旧笔记本低不少，比云主机当然没法比电费，但胜在一次性硬件投入后跑多久都免费。
更重要的是主板级的电源管理能力。很多 ARM 开发板对“来电后自动开机”支持得不好，要么需要额外写脚本，要么干脆不支持。ZimaBoard 作为 x86 板子，BIOS 里有 AC Power Loss 这类选项，可以把断电恢复策略直接设置在固件层——这意味着即使系统彻底断电，只要来电，主板就会自己重新上电。这个特性对无人值守场景几乎是刚需。
1.3 和树莓派、旧笔记本、云主机的取舍
我自己也纠结过一阵子，最后用一张表把方案摆开：
| 底座方案 | 功耗 | x86 兼容性 | 来电自启 | 综合成本 |
|---|---|---|---|---|
| 树莓派 | 极低 | 需 ARM 兼容 | 部分型号要外设方案 | 板子贵且内存吃紧 |
| 旧笔记本 | 中高 | 好 | 大多不支持 | 电费长期不划算 |
| 云主机 | 无法比较 | 好 | 无需关心，但收费 | 长期成本最高 |
| ZimaBoard | 低 | 好 | BIOS 原生支持 | 硬件一次性投入 |
对 OpenClaw 这种要 7x24 跑着的服务，省心比省那几百块更重要。树莓派其实也能跑，但 ARM 镜像偶尔会踩依赖坑，而且树莓派的 SD 卡在频繁断电下容易出问题；旧笔记本则输在长期电费和占地方。ZimaBoard 的定位恰好卡在中间：x86 生态、低功耗、有原生恢复能力。这也是我最终把它定成底座的核心原因。
2. 第一步改造：用 systemd 把 OpenClaw 变成“开机就会跑”的服务
2.1 先规划目录和运行用户，别让服务裸奔
很多人装 OpenClaw 时图方便，直接以 root 身份在/root下面跑，这是我在实战中第一个不建议的地方。root 用户下跑常驻服务，一旦被通过服务漏洞拿到执行权限，整个盒子就沦陷了。正确的做法是单独建一个普通用户，比如openclaw，并给服务划分独立目录：程序文件放/opt/openclaw，配置放/etc/openclaw，运行数据和日志放/var/lib/openclaw。
目录规划好之后，用chown -R openclaw:openclaw把这些目录属主改掉。这一步看似啰嗦，但后面配置 systemd 时会非常干净。服务不需要高权限，它只需要读写自己的数据目录、监听自己的端口。关于权限，我的经验是：给用户最小权限，比事后补救漏洞容易太多。
2.2 为什么选 systemd，而不是 rc.local 或 crontab
让程序开机自启，Linux 下有很多办法：rc.local加一行启动命令、crontab 写@reboot、systemd 单元服务。我知道很多人习惯前两种，因为它们“简单”。但简单只是表面的，rc.local和 crontab 都不会主动帮你处理服务崩溃后的重启、启动顺序、日志收集和状态查询。OpenClaw 这种服务需要的不是“开机执行一次”，而是“开机执行、运行中挂了自动拉起来、宕机重启后再执行”。
systemd 的单元文件能把这三件事一次说清楚：After=network-online.target决定启动时机，Restart=always决定崩溃后的行为，journalctl -u openclaw统一查看日志。如果你后面还要加定时任务、健康检查，systemd 的 timer 也能无缝扩展。所以我的建议很直接：别再用 crontab 凑合了，花十分钟写一个 unit 文件，长期收益比什么都高。
2.3 一个可以直接抄的 unit 文件
以常见的 Node 进程为例，假设 OpenClaw 的主入口是/opt/openclaw/dist/index.js，配置通过/etc/openclaw/openclaw.env加载，unit 文件可以这样写：
[Unit] Description=OpenClaw Self-hosted Service After=network-online.target Wants=network-online.target StartLimitIntervalSec=0 [Service] Type=simple User=openclaw Group=openclaw WorkingDirectory=/opt/openclaw EnvironmentFile=/etc/openclaw/openclaw.env ExecStart=/usr/bin/node /opt/openclaw/dist/index.js Restart=always RestartSec=5 TimeoutStopSec=30 KillSignal=SIGINT [Install] WantedBy=multi-user.target几个关键参数我展开说一下。Type=simple表示 ExecStart 启动的进程就是主进程，systemd 不需要等它 fork，日志直接从标准输出抓；如果你的 OpenClaw 是通过 shell 脚本包装启动的，记得去掉 shell 包装里可能有的&，否则 systemd 会认为主进程已经退出，从而反复重启。Restart=always是崩溃后无条件拉起的开关，RestartSec=5则加了 5 秒冷却，避免进程陷入“启动即崩溃、崩溃即启动”的风暴。
After=network-online.target和Wants=network-online.target是很多人容易漏掉的一对。单独写After是不行的，还要让系统在开机的过程中真正去等待网络就绪，Wants就是起这个作用。如果你的网络是 DHCP，这行尤其重要；静态 IP 也建议保留。没有这两行，开机脚本启动得早，OpenClaw 绑定端口时网卡还没拿到地址，直接就会失败。
2.4 安装和验证自启
把文件保存为/etc/systemd/system/openclaw.service，然后执行：
sudo systemctl daemon-reload sudo systemctl enable --now openclawenable --now的意思是：加入开机启动项，并且立刻启动。启动后先确认状态：
systemctl status openclaw systemctl is-enabled openclaw看到enabled且进程active (running)就说明本地已正常。但这只是第一次启动，还没验证“开机自启”。最快的验证方法不是拔电，而是直接sudo reboot。重启完成后自动登录或者 SSH 进去，再执行systemctl is-active openclaw，如果返回active，说明开机自启链路是通的。
这个验证方式成本低、可控性强，我建议每次改完 unit 文件都至少做一次。
3. 断电重启自动恢复：电源、系统、服务三件套
3.1 先搞定主板 BIOS 的来电自启
如果 ZimaBoard 来电之后连系统都没有启动，那上层再怎么配置都是白搭。x86 主板一般都有 AC Power Loss 或 Restore on AC Power Loss 的选项，默认值通常是 Power Off，也就是断电再来电，板子保持关机。这个设计是为了保护没有专人值守的设备，但对家庭服务器来说恰恰相反，我们需要的是 Power On。
进 BIOS 的方式各家略有不同，ZimaBoard 一般是在开机按 Del 或 F2。进入后在电源管理或高级设置里找到 AC Loss Recovery / Restore on AC Power Loss，改成立即开机（Power On）模式，保存退出。改完以后可以做一次全断电测试：拔掉电源线，等几秒，插回电，观察板子是否自动点亮。
这里有一个我实际踩过的小坑：BIOS 设置依赖主板上的纽扣电池维持 CMOS 内容，如果电池没电，你辛辛苦苦设好的来电自启策略可能在某次彻底断电后丢失，系统又回到默认关机状态。所以长期无人值守的板子，建议定期检查一下这个选项是否还在，或者干脆记录一下 BIOS 版本和配置，便于排查“为什么来电不自启”。
3.2 systemd 里的 Restart 策略是“运行中崩溃”的保险
开机自启解决的是“整机重启后服务要不要跟着起来”，而Restart=always解决的是“系统没重启但服务进程挂了怎么办”。这两个场景容易被混为一谈，但机制完全不一样。没有 Restart 策略的 unit，进程一旦退出，systemd 就放任不管；加上Restart=always后，只要是非正常退出，systemd 会在等待 RestartSec 后重新拉起。
always和on-failure的选择我单独说一下。always的含义是无论进程怎么退出，除了 systemctl stop 主动停止外，都重启；on-failure则只对非零退出码、被信号杀死等情况生效。对 OpenClaw 这种服务，我建议用always，因为它可能会因为内存不足被内核杀死，也可能在升级时自己优雅退出，这两种情况你都希望它能自动回来。再加上StartLimitIntervalSec=0，可以取消 systemd 默认的“启动失败次数过多就放弃”限制。当然，如果服务本身存在配置错误，无限重启会掩盖问题，所以实际部署时最好配合健康检查，见后面第 4 章。
3.3 数据持久化：断电后最怕的不是起不来，是数据坏掉
断电自动恢复的本质是“恢复到断电之前的状态”，如果 OpenClaw 的数据库或缓存文件在断电瞬间损坏，那么服务即使起来也会报错退出。为了减少这类风险，我做了三件事：
第一，系统盘和 OpenClaw 数据盘都放在 SSD 上，不要放在 U 盘或 SD 卡上。SSD 虽然也存在掉电丢数据的可能，但比 Flash 存储的抗掉电能力强很多。第二，给数据目录挂独立分区，并使用 ext4 文件系统，它的日志机制在异常断电后能自动回放，配合开机时系统自带的 fsck 检查，大部分情况下文件系统能自愈。第三，在 systemd unit 里加入ExecStartPre检查，启动服务之前先清理掉上次异常退出残留的 pid 文件和锁文件。
下面这个 precheck 脚本是我实际在用的简化版：
#!/bin/bash # /usr/local/bin/openclaw-precheck.sh LOCK_FILE=/var/lib/openclaw/openclaw.pid if [ -f "$LOCK_FILE" ]; then # 如果 lock 文件存在，先检查对应进程是否还活着 OLD_PID=$(cat "$LOCK_FILE") if ! kill -0 "$OLD_PID" 2>/dev/null; then rm -f "$LOCK_FILE" fi fi exit 0然后把它挂到 unit 里：
ExecStartPre=/usr/local/bin/openclaw-precheck.sh这个脚本本身不复杂，但能挡住相当一部分“断电后起不来”的问题。同样的思路也适用于 SQLite 数据库：启动前用sqlite3 /var/lib/openclaw/data.db "PRAGMA integrity_check;"做一次完整性检查，发现异常就先把备份文件恢复过来。
3.4 如果你用 Docker 部署 OpenClaw
如果你的 OpenClaw 是用 Docker 容器跑的，上面的 systemd unit 就不需要写了，对应概念落在 Docker 的 restart policy 上。在docker-compose.yml里给服务加上：
services: openclaw: image: your-registry/openclaw:latest container_name: openclaw restart: unless-stopped volumes: - ./openclaw-data:/data - ./openclaw-config:/configunless-stopped的效果是：容器异常退出会自动重启，Docker daemon 重启后容器也会跟着起来，只有你手动docker compose stop后它才保持停止。这和always很接近，区别是always在手动 stop 后依然会在 Docker daemon 重启时拉起。对常驻服务来说，unless-stopped是更符合直觉的选择，省得你哪天想停服务却怎么都停不掉。
Docker 方式还有一个额外好处：容器本身的文件系统隔离了部分数据损坏风险，只要 volume 映射做好，重建容器不影响数据。但代价是日志要经过 Docker 的 json-file 驱动，磁盘占用往往比原生 systemd 日志更多，这块需要单独配置日志轮转。
4. 一次完整的断电模拟实测：从“没起来”到“稳定恢复”
4.1 测试前先记录基线
改完系统配置后，最好先做一次完整的断电模拟。但别一上来就拔插头，先把基线信息记录下来：
systemctl is-enabled openclaw应该是 enabled；systemctl status openclaw应该是 active (running)；ss -lntp | grep 3000能查到你配置的端口正在监听；- 随机访问一次健康检查接口，确认响应正常。
这些信息是恢复测试的对照组。没有基线，你没法判断重启后的异常是配置问题还是本来就有的问题。
4.2 模拟断电的两种方式与观察项
模拟断电有两种办法。第一种是sudo systemctl poweroff，代表正常关机流程，验证的是“开机自启”；第二种是直接拔掉电源线，过几秒再插回，验证的是“断电 + 来电自启 + 服务拉起”的完整链路。我建议先做第一种，再拔电。第一次就拔电，万一 BIOS 设置没生效，你会分不清是系统问题还是服务问题。
拔电重插后，观察顺序是：先看板子是否自动开机（电源灯、风扇、SSH 通不通），再看/var/log/syslog或journalctl -b里有没有系统恢复的记录，最后看 OpenClaw 是否在监听端口。如果板子没自动开机，回第 3 章查 BIOS；如果开机了但服务没起来，进入下面的排查链路。
4.3 排查链路第一站：systemctl 状态和历史日志
SSH 登录后第一件事不是重启服务，而是把现场留证：
systemctl status openclaw journalctl -u openclaw -b --no-pager | tail -80最典型的情况是systemctl is-enabled返回disabled。很多人安装服务时只做了systemctl start，忘了systemctl enable，于是每次开机都起不来。这个错误太常见了，几乎可以排在断电恢复失败原因的第一位。解决办法就是执行sudo systemctl enable openclaw，然后重启再验证。
如果enabled但状态是failed，看日志。如果日志里有EADDRNOTAVAIL或者Cannot assign requested address，说明进程启动时网络还没就绪，去检查 unit 文件有没有After=network-online.target和Wants=network-online.target。如果是静态 IP，还需要确认 systemd-networkd 或 NetworkManager 的connectivity检查是否打开，某些发行版默认不等待“网络可用”，只等待“网络设备出现”，这里很容易踩坑。
4.4 排查链路第二站：残留锁文件与数据文件
日志里如果没有网络错误，服务却还是反复退出，那基本可以断定问题出在数据侧。强制断电后，OpenClaw 的 pid 文件、SQLite 数据库的-journal文件、临时目录里的 socket 文件都可能残留。程序启动时发现 pid 文件指向的进程不存在还好，如果锁文件被误判为“服务正在运行”，它会直接拒绝启动。
我在日志里看到过比较典型的报错是Address already in use，但ss -lntp查端口明明没进程监听。这种情况多半是程序自己维护的 socket 文件或者锁文件没清干净，不是真的端口占用。此时按第 3 章的 precheck 逻辑处理即可。另外，如果 OpenClaw 依赖 SQLite，断电可能造成数据库 journal 文件残留，程序启动时检测到“上一次事务未完成”会拒绝打开数据库。这种情况可以手动运行一次PRAGMA integrity_check，或者把备份还原过来。所以数据备份不是可选操作，而是断电恢复的底线保障。
4.5 最后一道兜底：健康检查加看门狗
就算做好了所有配置，我还是建议加一道外部看门狗。原因很简单：systemd 能在进程崩溃时拉它起来，但如果进程没有崩溃而是进入死锁、OOM 假死状态，端口依然存在，systemctl status也依然显示 active，实际上服务却已经不可用。OpenClaw 这类自托管服务尤其容易在长时间运行后出现这种“僵尸在线”的状态。
一个很实用的做法是写个健康检查脚本，每两分钟探测一次端口或健康检查接口，失败就强制重启服务：
#!/bin/bash # /usr/local/bin/openclaw-watchdog.sh HEALTH_URL="http://127.0.0.1:3000/health" if ! curl -fsS --connect-timeout 5 --max-time 10 "$HEALTH_URL" >/dev/null 2>&1; then systemctl restart openclaw echo "$(date '+%Y-%m-%d %H:%M:%S') openclaw restart triggered" >> /var/log/openclaw-watchdog.log fi然后用 crontab 挂上：
*/2 * * * * /usr/local/bin/openclaw-watchdog.sh这样一来，即使前面所有环节都没拦住问题，最坏情况下服务也会在两分钟之内被兜底重启。实测中这个脚本帮我处理过至少三次内存泄漏导致的假死，非常值。
5. 长期稳定运行后，我做的几个不后悔的小优化
5.1 限制 systemd 日志大小
OpenClaw 跑起来之后日志会持续输出。systemd 的 journal 默认不设上限，时间一长磁盘可能悄悄被日志占满。磁盘满之后，服务写不了日志和缓存，各种奇怪问题接踵而来。我在/etc/systemd/journald.conf里做了限制：
SystemMaxUse=200M SystemMaxFileSize=50M改完以后重启systemd-journald服务让配置生效。对 OpenClaw 这种量级的服务，200M 日志能保留足够长时间做排查，又不会威胁系统磁盘。如果你用 Docker，则要在 Docker daemon 或 compose 里配置 log rotation，道理一样——日志不管好，早晚反噬。
5.2 增加启动完成通知
无人值守场景下，恢复是否成功不能靠肉眼确认。我后来在 unit 的ExecStartPost里加了一行 curl，把启动结果推到家中的消息通知通道。具体怎么实现取决于你的通知渠道，但思路很简单：服务启动成功后，让系统告诉你一声“我活了”。这样你不需要每次断电后都主动去查，而是等通知。
如果你不想动 unit 文件，也可以用前面的 watchdog 脚本在旁边顺带处理：每次重启后追加一行日志，再调用一次通知接口。我倾向于第二种方式，因为它把“检查-重启-通知”三个动作放在一起，逻辑更集中，不会因为某一次启动失败而漏报。
5.3 供电与散热的小叮嘱
ZimaBoard 的功耗虽然不高，但挂了 SSD 之后瞬时功耗会上升，电源适配器尽量不要选刚好够用的那种，留出 20% 左右的余量会稳得多。散热方面，无风扇机箱长时间跑服务要注意温度，尤其夏天弱电箱通风差，建议在健康检查脚本里顺带读一下 CPU 温度，温度过高就通知你，别真等到硬件报警。
另外，如果你的使用场景经常断电，可以认真考虑加一个小型 UPS。UPS 的意义不只是避免服务中断，更重要的是给 SSD 和文件系统一个优雅关机的机会，把断电对数据的损伤降到最低。我之前一直觉得家用 UPS 是过度配置，直到某次停电后 SQLite 数据库需要从备份恢复，才明白几十块钱的投入其实很值得。
5.4 最后分享一个实用习惯
我自己的经验是，所有关于自启和恢复的配置，最好写成一篇简短的运维笔记，记录三件事：unit 文件的最终版本、BIOS 电源策略的设置位置、健康检查脚本的路径。因为这类配置平时不碰，半年后想出问题可能完全想不起来在哪改过。拿我这台 ZimaBoard 来说，当 OpenClaw 又“神秘消失”的时候，翻笔记比翻 memory 快得多。
