systemd服务应在network.target就绪后启动,需在[unit]中声明after=network.target,可叠加local-fs.target或mysql.service等依赖,禁用sleep或ping检测,配置后通过list-dependencies验证顺序。

让 systemd 服务在网络就绪后启动,关键是在服务单元文件的 [Unit] 区块中正确声明依赖关系。这不是“等网络通了再运行”,而是按 systemd 的依赖图机制,在 network.target 就绪之后才开始启动你的服务。
明确指定 After=network.target
这是最常用且推荐的方式。在服务文件的 [Unit] 部分加入这一行:
-
After=network.target:表示该服务应在network.target激活之后启动 - 它不保证所有网卡已配置完成或互联网可达,只代表基础网络子系统(如 systemd-networkd 或 NetworkManager)已准备就绪
- 适用于大多数需要联网能力的服务,比如调用 API、连接远程数据库、发送邮件等
根据实际需求补充其他依赖
单靠 network.target 不一定满足全部前提。若服务还依赖其他资源,可叠加声明:
在无 root/sudo 权限的环境(云容器、VPS、隔离主机)中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景:...
- 需要本地磁盘挂载完成 → 加上
After=local-fs.target - 需等待特定服务(如 MySQL)就绪 → 加上
After=mysql.service,并建议同时写Wants=mysql.service或Requires=mysql.service - 若脚本依赖 DNS 解析,而 DNS 由 NetworkManager 管理,则
network.target通常已隐含覆盖;但若使用 systemd-resolved,也可加After=systemd-resolved.service
避免常见误区
有些做法看似合理,实则无效或危险:
- 不要用
sleep 10或循环 ping 来“等待网络”——这违背 systemd 的声明式设计,且不可靠 - 不要把
ExecStart写成/bin/bash -c 'ping -c1 google.com && python app.py'—— 这会让服务状态判断失真,systemd 无法准确识别进程是否真正就绪 - 不要省略
WantedBy=multi-user.target—— 否则systemctl enable不会生效
验证是否生效
配置完成后,务必测试依赖顺序是否按预期工作:
- 重载配置:
sudo systemctl daemon-reload - 启用服务:
sudo systemctl enable your-service.service - 查看启动顺序:
systemctl list-dependencies --after your-service.service,确认network.target在列表中 - 模拟开机流程:
sudo systemctl isolate multi-user.target,再检查服务状态和日志:sudo journalctl -u your-service.service -n 20










