开机启动脚本未执行的主因是环境、权限或时机问题，需从执行主体、运行上下文和系统阶段排查；先确认服务是否启用并加载成功，再查日志、验证执行环境及依赖条件。
开机启动脚本“配置了却没执行”，最常见不是脚本写错了，而是环境、权限或时机出了问题。排查要从执行主体、运行上下文和系统阶段三方面入手，而不是反复改脚本逻辑。
看服务是否真被启用且加载成功
先确认 systemd 是否识别并启用了你的服务：
- 运行 sudo systemctl list-unit-files --type=service | grep your-service-name，检查状态是否为 enabled（不是 static 或 disabled）
- 执行 sudo systemctl daemon-reload 后再 enable，避免配置变更未生效
- 如果服务名含下划线或特殊字符，systemd 可能解析异常，建议用短横线（如
my-script.service）
查日志：重点看启动瞬间发生了什么
手动 start 成功但开机不运行，说明问题出在启动时的上下文差异：
- 用 sudo journalctl -u your-service-name --since "1 hour ago" 查服务专属日志
- 加 -b 参数看本次启动全程：sudo journalctl -u your-service-name -b
- 若无输出，可能是服务根本没触发——再查 sudo journalctl -b | grep -i "your-service-name\|failed\|start"
验证脚本执行环境是否就绪
开机时的 root 环境和你终端里完全不同：
- 在脚本开头加一行：env > /tmp/boot_env.log 2>&1，重启后对比 env 输出，重点关注
PATH、HOME、PWD - 所有路径必须是绝对路径：
/usr/bin/python3不是python3，/home/user/script.py不是./script.py - 如果依赖 conda/virtualenv，不能只写
source activate env；要用完整路径调用解释器，例如/home/user/miniconda3/envs/myenv/bin/python
确认依赖条件是否满足
很多失败是因为服务启动太早，关键资源还没准备好：
- 检查
[Unit]段中 After= 是否合理：需要网络？加After=network.target；需要挂载磁盘？加After=local-fs.target - 避免写
After=multi-user.target就完事——它不保证网络或文件系统已就绪 - 临时加
ExecStartPre=/bin/sleep 10测试是否纯时机问题（仅用于定位，勿长期使用）
