服务无法开机自启，首要排查服务是否被系统正确注册：检查/etc/systemd/system/下.service文件存在且命名规范，用systemctl list-unit-files确认启用状态；若未启用则需daemon-reload并enable；再通过systemd-analyze verify验证配置语法，确保user存在且家目录权限≥755；最后用journalctl查具体失败步骤及权限错误。
服务无法开机自启，问题往往不出在“脚本没写好”，而卡在 systemd 加载、权限上下文、依赖时序这些隐性环节。排查要按顺序推进，跳过任何一步都可能白忙活。
第一步：确认服务是否真被系统注册
很多故障其实止步于“服务压根没进系统视野”。别急着看日志，先验证基础存在性：
- 检查文件位置和命名：/etc/systemd/system/ 下必须有以 .service 结尾的文件，不能是子目录、.service.txt 或大小写错误（如 SERVICE）
- 执行 systemctl list-unit-files --type=service | grep your-service —— 这是最权威的开机自启状态来源，只显示真正注册成功的服务
- 若无输出或显示 disabled，说明未启用；运行 sudo systemctl daemon-reload && sudo systemctl enable your-service.service 补全流程
第二步：检查服务加载是否成功
文件存在 ≠ 能被正确解析。语法错误、路径非法、User 指定不存在等都会导致加载失败，但 enable 命令不会报错：
- 运行 sudo systemd-analyze verify /etc/systemd/system/your-service.service，直接暴露配置语法问题
- 查看加载状态：systemctl status your-service.service 中 “Loaded” 行末尾应为 enabled；若显示 not-found 或 invalid，说明加载失败
- 特别注意 User= 字段：该用户必须真实存在，且其家目录至少有 755 权限（否则 ~/.ssh 等路径访问直接 Permission denied）
第三步：定位启动失败的具体环节
systemctl status 只显示最后一行摘要，真正线索藏在完整日志里：
- 先看关键提示：systemctl status your-service.service 中关注 Failed at step XXX，比如 Failed at step EXEC spawning（执行失败）、Failed at step CHDIR spawning（工作目录不可访问）
- 查完整过程：journalctl -u your-service.service -n 100 -o cat，重点搜索 Permission denied、No such file or directory、Cannot open config 等关键词
- 常见陷阱：ExecStart 路径不是绝对路径；解释器（如 /usr/bin/python3）或配置文件（如 /etc/myapp/conf.ini）对指定 User 不可读；日志目录（如 /var/log/myapp）对 User 不可写
第四步：验证运行上下文与手动执行是否一致
手动 systemctl start 成功 ≠ 开机自启成功。因为开机时 systemd 启动服务的环境更“干净”——没有你的 shell 环境变量、没有当前工作目录、权限上下文也不同：
- 模拟开机环境测试：sudo -u your-user /bin/bash -c 'cd /path/to && /path/to/executable --help'，看是否报错
- 检查所有依赖路径：脚本本身、解释器、配置文件、日志目录、临时目录、SSH 密钥路径……全部需对 User= 指定的用户可读可写可执行
- 避免硬编码 root 路径：比如 /root/config.yaml 对普通用户永远不可读，应改用 /etc/ 或 /var/lib/ 下的全局路径
