经常跑服务的单板小主机，最怕的就是断电。一台 ZimaBoard 放在桌下安安静静，可一旦半夜电压波动或者总闸跳了，等来电之后它要是干瞪眼不干活，你就得翻出显示器接上、登录终端，手动启动 OpenClaw。这种场景我遇过不止一次，后来专门花了一整天把开机自启和断电恢复整套理顺。这篇记录就是折腾过程的完整复盘，顺便把容易踩的坑都标出来。
ZimaBoard 这类小主机的定位就是低功耗常驻，理论上重启之后所有服务应该自动回来，但现实往往不是这样：OpenClaw 可能依赖数据库、可能依赖外部存储，也可能你自己都忘了它到底是怎么被拉起来的。把自启做扎实，不只是图省事，更是让“常驻”这两个字真正成立的前提。我会从最基础的 systemd 方案讲到容器场景，最后列几个调试实例，尽量让不同部署方式的读者都能找到参考。
1. 为什么要在 ZimaBoard 上做“开机自启 + 断电恢复”
1.1 场景痛点：断电之后手忙脚乱
我用 ZimaBoard 跑 OpenClaw，主要用于把家里的几个自动化任务统一管理起来。平时看着是台不起眼的小盒子，但它承载的工作一旦断掉，影响立刻能感受到。第一次遇到意外断电时，我在外面出差，回家才发现整个服务已经停了小半天，而 ZimaBoard 本身已经开机了，OpenClaw 却一直没起来。
这就是单板小主机最尴尬的地方：硬件通电只是第一步，软件要不要起来、按什么顺序起来、起来之后能不能正常工作，全都是另外的问题。尤其是 OpenClaw 这类带状态的服务，如果它依赖的中间件没就绪，你一上来就给做主进程启动，大概率会失败，然后你就得手动干预。体验几次之后我很确定，必须设计一套从上电到业务可用的“自动恢复链条”。
1.2 部署方式决定了自启的复杂度
OpenClaw 的部署方式会直接影响恢复方案。如果直接以裸进程方式跑在系统里，最合适的自启工具就是 systemd；如果跑在容器里，更多要用到 Docker 的 restart 策略。两者并不是非此即彼——很多人的真实情况是 OpenClaw 本体用 systemd 管，但它依赖的数据库或者消息队列跑在容器里。
我见过不少朋友在做自启的时候只盯着主进程，忽略了依赖顺序和失败重试，结果每次异常断电后主服务虽然自动启动了，却因为等不到依赖而循环重启。所以这篇文章会按两种主流部署方式分别展开，并给出我实测下来比较稳的配置组合。
2. 动手前的准备：系统、目录与 BIOS 设置
2.1 确认 ZimaBoard 的系统与架构
我的 ZimaBoard 刷的是 Debian 系的 Linux 系统，这也是这块板子比较常见的运行环境。开始配置前，先用下面命令确认系统和架构：
cat /etc/os-release uname -m我这边是 x86_64 架构，用的 systemd 作为初始化系统。如果你的 ZimaBoard 刷的是其他系统（比如某些精简镜像），可能需要换一套启动工具，但绝大多数场景下 systemd 都是默认方案。确认好这些信息，后续的 unit 文件才有意义。
2.2 准备 OpenClaw 的数据目录与运行用户
自启配置的一个重要原则：不要让服务以 root 身份一路跑到地老天荒。我给 OpenClaw 单独建了系统用户和目录，这样即使服务出问题，也不会把整个系统权限暴露出去。操作很简单：
sudo useradd -r -s /usr/sbin/nologin openclaw sudo mkdir -p /opt/openclaw/data sudo chown -R openclaw:openclaw /opt/openclaw数据目录独立出来还有一个好处：后续如果系统升级或者重装，只要把这个目录备份好，OpenClaw 的配置和状态都能恢复。很多人忽略这一步，自启是成功了，但每次重启后服务状态“看起来正常，实际情况却丢了不少”，原因往往就是状态数据写在临时目录里，开机一重启就没了。
2.3 BIOS 里的“上电自动开机”选项
这是断电恢复中最容易被忽略的一个环节。ZimaBoard 默认在“断电来电后”可能会停留在关机状态，需要把 BIOS 里的电源恢复模式调整为“上电开机”或“Restore AC Power Loss”为 Power On。每家的 BIOS 名称不完全一样，但思路一致：让硬件在检测到交流电恢复后，自己完成一次冷启动。
这一步必须在操作系统层面之前做好，否则后面所有软件自启都是空谈。我在这块板子上折腾过，刚开始软件配置全做完了，断电测试才发现机器根本没开机，排查半天是 BIOS 里默认选择的是“保持之前电源状态”，而断电前是关机状态，所以来电后自然不开机。改掉之后，整个自动恢复链条的第一环才算打通。
3. 用 systemd 实现裸进程自启
3.1 编写一个合格的 service 单元文件
如果你直接把 OpenClaw 的可执行文件放在系统里跑，不经过容器，那 systemd 就是最佳控制器。我在/etc/systemd/system/openclaw.service里写了这样的配置：
[Unit] Description=OpenClaw Service After=network-online.target Wants=network-online.target [Service] User=openclaw Group=openclaw WorkingDirectory=/opt/openclaw ExecStart=/usr/local/bin/openclaw serve --config /opt/openclaw/openclaw.yml Restart=on-failure RestartSec=5 StartLimitIntervalSec=0 TimeoutStopSec=20 [Install] WantedBy=multi-user.target这里有几个关键点，值得展开说明。After=network-online.target并不是保证网络已经就绪，而是告诉 systemd 在达到“网络在线”这个目标之后再启动本服务。配合Wants=network-online.target，可以避免 OpenClaw 一开机就抢跑，然后因为连不上外部依赖而退出。Restart=on-failure是核心，服务进程异常退出时 systemd 会尝试拉起；RestartSec=5给依赖服务留出缓冲时间。StartLimitIntervalSec=0的意思是取消重启次数限制，避免因为多次重启达到 systemd 默认的速率上限后直接放弃。
3.2 让配置生效并测试自启
写完 unit 文件后，执行：
sudo systemctl daemon-reload sudo systemctl enable openclaw.service sudo systemctl start openclaw.serviceenable这一步很关键，它就是在系统各运行级别中建立软链接，让服务随开机自启。仅 start 而不 enable，下次重启还是会熄火。建议开启后再用systemctl is-enabled openclaw确认状态。
测试恢复正常流程时，我一般直接重启系统：
sudo reboot重启完成后马上看服务状态：
systemctl status openclaw -l如果服务处于active (running)，基本就算通过。为了测试异常自动恢复，还可以直接杀掉进程：
sudo kill -9 $(pgrep -f 'openclaw serve')正常情况下 systemd 会在几秒内自动把它拉回来。这一步验证的是 Restart 策略是否真正生效。
3.3 为什么不用/etc/rc.local
如果是在老到用 SysVinit 的系统上，rc.local可能还有意义，但 ZimaBoard 的主流系统早就是 systemd 一统天下。有人图省事往/etc/rc.local里塞启动命令，结果重启顺序完全不可控，也没有进程守护，进程一崩就只能干瞪眼。systemd 对服务依赖、重启策略、日志采集都有统一管理，既然现成的轮子这么好用，没必要回到手工脚本时代。
4. 如果你用容器跑 OpenClaw，自启该怎么配
4.1 Docker restart 策略的选择
很多人在 ZimaBoard 上喜欢用 Docker 跑应用，OpenClaw 自然也可以容器化。Docker 提供了原生的重启策略，写在docker run里或者 compose 文件中都能生效。我推荐的原则是：需要长期运行的服务，用restart: unless-stopped；需要严格依赖其他容器的服务，再配合健康检查和依赖等待。
unless-stopped和always的差异在于：前者会在容器被手动docker stop之后不自动启动，后者即使你手动停了，Docker 服务重启时也会把它拉起来。对于 OpenClaw 这种服务，我选unless-stopped，因为有时候维护时我需要主动停掉它，不希望它反复被拉起来。
4.2 用 docker-compose 管理依赖顺序
一个典型的 docker-compose 配置可能长这样：
services: redis: image: redis:7-alpine restart: unless-stopped healthcheck: test: ["CMD", "redis-cli", "ping"] interval: 10s timeout: 3s retries: 5 openclaw: image: openclaw-local:latest restart: unless-stopped depends_on: redis: condition: service_healthy ports: - "8081:8081"这里最关键的是depends_on里的condition: service_healthy。如果只写depends_on而不加条件，docker-compose 只会等容器被创建，不会等它内部就绪。我曾经踩过这个坑：OpenClaw 容器起来后发现 Redis 还处在初始化阶段，连接失败后连续重启，看起来是“自启失败了”，其实就是没有健康检查。
注意：depends_on只能管理同一 compose 文件内的容器。如果 OpenClaw 依赖的是宿主机上另一个 systemd 服务，就没有办法直接声明依赖，只能靠启动延迟或者应用自身的重试机制兜底。
4.3 容器自启之外，别忘了 Docker 服务的自启
如果你的 ZimaBoard 用的是 Docker 官方安装脚本，Docker 服务本身应该已经配置为 systemd 自启。不过仍然建议检查一下：
sudo systemctl is-enabled docker如果输出disabled，需要在开启其他容器自启前先修复：
sudo systemctl enable docker因为所有基于 restart 策略的容器，都依赖 Docker daemon 在开机时先跑起来。这也是一环扣一环的典型例子：BIOS 负责上电，systemd 负责拉起 Docker，Docker 再根据 restart 策略拉起容器。
5. 断电恢复场景的关键细节
5.1 外部存储挂载必须先于主服务
很多人的 ZimaBoard 会挂 USB 硬盘或者外置 SSD，OpenClaw 的数据目录也放在上面。如果 systemd 在文件系统挂载之前就把服务拉起来，进程能启动，但读写日志时会疯狂报错。我遇到过两次这类问题，后来在 unit 文件里加了一条：
After=local-fs.target Requires=local-fs.target再加上 systemd 还会等待local-fs.target之前定义的挂载点完成，基本能解决。如果用 systemd mount 单元管理外部存储，最好在 OpenClaw 的 unit 文件里写明：
Requires=mnt-data.mount After=mnt-data.mount这样做的好处是把“存储就绪”从“网络就绪”里独立出来，防止网络相关等待阻塞挂载，或者反过来。断电恢复时最容易出现的问题，就是系统快速启动后存储设备还没准备好，服务却已经开始读写了。
5.2 延迟启动与健康检查的平衡
有些服务对“等多久”没有耐心，宁可晚一点启动也不愿意反复失败。我习惯在 OpenClaw 的 systemd 服务里加一个短小的延时：
ExecStartPre=/bin/sleep 5别滥用这个方案，但如果你的服务没有任何重试机制，一个 5 到 10 秒的延时成本很低，却能让网络和存储完全就绪。容器场景则更推荐健康检查，而不是单纯 sleep——因为健康检查是动态判断，sleep 是盲等。断电后系统负载高，各服务启动时间并不固定，盲等一次可能不够，也可能等多了。
5.3 日志与验证闭环
自动恢复不是配完就能一劳永逸，至少要有一次“来电后不干预”的验证。我在一天内做了两次断电测试：一次是直接拔掉电源，等五秒再插上，然后观察 ZimaBoard 是否自动开机、OpenClaw 是否自动恢复；另一次是杀掉 OpenClaw 进程，看 systemd 是否能自动拉起。
日志方面，用 journald 天然适合查看启动过程是否正常：
sudo journalctl -u openclaw -b -n 100-b是只看本次启动的日志，这个参数在排查断电恢复时价值很大。它能把系统启动到现在服务的完整日志拉出来，判断服务是在第几秒启动、有没有报错、依赖是否到位。
6. 常见问题与排查实录
6.1 服务起不来：目录权限和日志
典型症状：开机后systemctl status openclaw显示failed，或者进程在反复重启。第一种思路是看日志，日志里常出现Permission denied或者open /opt/openclaw/openclaw.yml: no such file or directory。
权限问题大多因为我给服务设置了指定的 User/Group，但目录还是 root 所有。解决方法是把数据目录的所有权交出去：
sudo chown -R openclaw:openclaw /opt/openclaw另外注意 SELinux 或者 AppArmor 如果处于强制模式，可能会阻止进程读取某些路径。ZimaBoard 的默认系统一般没开 SELinux，但如果你额外配置过，需要放行对应目录。
6.2 启动顺序不对：依赖没声明
症状：OpenClaw 进程起来了，但日志里全是连接失败，然后不断重启。对应上文提到的依赖问题。如果在 systemd 下，检查 unit 里的After和Requires是否覆盖了所有关键依赖；如果在 Docker 下，确保depends_on配了condition: service_healthy，并且依赖容器确实定义了健康检查。
我个人的排查顺序是：先看systemd-analyze blame或残留的日志时间戳，确认主服务启动得有多早，然后在依赖项的 unit 文件里确认它是否也设置了自启。往往问题不是主服务配置写错，而是依赖服务根本没有 enable，导致After=xxx.target变成无效等待。
6.3 断电后没有自动开机：BIOS 设置没生效
如果断电来之后 ZimaBoard 完全没动静，指示灯都不亮，那问题在硬件层。回到 BIOS 里找电源管理相关选项，把“AC Power Loss”设成 Power On。设置完以后，建议做一次完整测试：关机、拔电源、等几秒、插上电源。这时不需要按任何按钮，机器应该自己启动。
有次我改完 BIOS 但忘记保存，重启后又回到默认状态，导致整个自动化链路看起来没做错什么，就是不通。后来养成了习惯：改完 BIOS 后重启进去确认一次，再断电验证。
6.4 容器自启后状态异常：健康检查未定义
现象：容器确实起来了，但业务不可用，进容器看日志发现一直在等依赖。追根到底是依赖容器没有健康检查，depends_on的condition自然无法生效。正确的做法是在每个中间件容器里定义 healthcheck，而不是只定义在 OpenClaw 上。健康检查的路径要选得准：像 Redis 用redis-cli ping，数据库用原生查询命令，Web 服务用 HTTP 探活。
7. 最后再分享几个实操细节
个人经验里，最值得记的一条是：自启配置本身就是一个小型项目，最好把 unit 文件和 compose 文件都用 git 管理起来。ZimaBoard 这类机器一旦系统损坏，重新刷机后你要做的事不是回忆当初怎么配的，而是直接拉配置、改路径、一键启用。
另外不要只测一次就完事。断电恢复涉及 BIOS、systemd、Docker 三层，每一层的状态都可能被系统更新或者误操作改变。我给自己定的检查频率是一个月断电演练一次，五秒钟的事，省去出问题时的长时间排查。
如果你在 ZimaBoard 上跑的服务不止 OpenClaw，那么建议给每个服务建一个独立的 systemd unit 或者独立的 compose 文件，并把依赖关系写成文档放在/opt/openclaw/README.md旁边。这比任何漂亮的自启脚本都值钱——因为半年后你可能早忘了哪条配置是因为什么原因加进去的。我还习惯在配置里加一行注释，记录第一次遇到该问题时的现场日志，这样来回看时能快速定位。
搞定了这些，ZimaBoard 才算真正成为一台可以无人值守的小服务器。下次断电再来，它会自己醒过来，继续干活。
