先用 journalctl -u service.service -n 50 -f 查看实时日志，重点关注“failed with result”或“exited, status=”行；再用 systemctl status 快速定位失败摘要，结合 restart=、依赖配置和 daemon-reload 等操作排查。
systemd 服务启动失败时怎么看日志
服务起不来，别急着改配置，先看 systemd 记录的真实错误。最直接的方式是用 journalctl -u <service-name>.service -n 50 -f</service-name> 实时盯住日志，尤其注意带 Failed with result 或 exited, code=exited, status= 的行——这些才是真正的死因。
常见错误现象：
-
Failed to start MyApp.service: Unit not found.→ 服务文件没放对位置，或没 reload -
Failed at step EXEC spawning /path/to/app: No such file or Directory→ExecStart路径写错，或二进制没加执行权限 -
main process exited, code=exited, status=1/FAILURE→ 应用本身启动就崩了，得结合应用日志看
实操建议：
- 改完
.service文件后，必须运行sudo systemctl daemon-reload，否则 systemd 完全不认新配置 - 用
sudo systemctl status <service-name>.service</service-name>看当前状态和最近一次失败的摘要，比翻长日志快得多 - 如果服务依赖网络或其它服务（比如数据库），记得在
[Unit]段加After=network.target或Wants=postgresql.service，否则可能抢在依赖之前启动
让服务崩溃后自动重启的关键参数
不是所有服务都适合自动重启，但多数后台进程（如 API 服务、消息消费者）需要它。核心靠 Restart= 和配套的 RestartSec=，但不同值的行为差异很大，选错反而掩盖问题。
常用组合与适用场景：
-
Restart=on-failure：只在非 0 退出码、被信号终止（如 SIGKILL 除外）、超时等“异常退出”时重启 —— 最常用，适合大多数守护进程 -
Restart=always：不管怎么退出都重启 —— 容易掩盖配置错误（比如每次启动都因参数错退出，然后无限循环），慎用 -
Restart=on-abort：仅当被 SIGABRT 终止才重启 —— 很少用，多见于调试场景
必须配合的参数：
-
RestartSec=5：两次重启之间至少等 5 秒，避免夯住系统；太小（如 1）可能触发 systemd 的 rate limit，导致服务被 temporarily disabled -
StartLimitIntervalSec=60和StartLimitBurst=3：默认 60 秒内最多启动 3 次，超了就锁死 —— 这是保护机制，不是 bug；若真需要高频重启，得显式调大
服务启动顺序和依赖关系怎么写才可靠
很多服务卡在 “activating (start)” 状态不动，八成是依赖没写对。systemd 不是按文件名排序加载，而是严格按 [Unit] 段里的 After=、Wants=、Requires= 解析依赖图。
关键区别：
-
Wants=：软依赖，目标服务启动失败不影响本服务启动 -
Requires=：硬依赖，目标服务启动失败，本服务直接标记为 failed -
After=：只控制顺序，不保证目标一定成功；必须搭配Wants=或Requires=才有意义
实操踩坑点：
- 想等网络就绪？别写
After=network.service（已废弃），改用After=network-online.target+Wants=network-online.target - 依赖 docker 容器？不要写
Wants=docker.service，而应写After=docker.service并确保 docker 已启用（sudo systemctl enable docker） - 自定义脚本依赖环境变量？
EnvironmentFile=必须放在[Service]段开头，且路径必须绝对（如/etc/myapp/env），相对路径会静默失效
systemctl enable 和 start 的实际效果差异
sudo systemctl start myapp.service 是临时启动，机器重启后就没了；sudo systemctl enable myapp.service 才是让它开机自启——但很多人忽略 enable 的本质：它只是在 /etc/systemd/system/multi-user.target.wants/ 下建个符号链接，指向你的 .service 文件。
所以真正生效的前提是：
- 服务文件必须放在 systemd 能扫描到的位置：
/etc/systemd/system/（推荐，优先级最高）或/usr/lib/systemd/system/ - 文件名必须以
.service结尾，且内容符合语法（可用sudo systemctl daemon-reload && sudo systemctl cat myapp.service验证是否被识别） - enable 后不会立即启动服务，要手动
start或重启机器才第一次运行
容易被忽略的细节：
- 如果服务文件在
/etc/systemd/system/下，但名字是myapp（没后缀），enable会静默失败，且不报错 - 修改服务文件后只
enable不daemon-reload，旧配置仍生效；反过来，只daemon-reload不enable，则下次重启后失效 - 想彻底禁用？用
sudo systemctl disable myapp.service删除软链，再sudo systemctl stop myapp.service停掉当前实例
复杂点在于：有些服务（比如用 Type=notify 的）要求应用自己调用 sd_notify() 告知 systemd “我准备好了”，否则 systemd 会一直等超时；这种情况下，光配对参数没用，代码里也得配合。