排查systemd开机启动故障需聚焦权限、用户组和环境三方面：先确认脚本有执行权限（chmod +x），再检查user/group是否匹配资源访问需求，最后显式声明path、home等环境变量并查journalctl日志定位具体错误。
排查开机启动项权限配置不当的故障，核心是确认“谁在跑、能碰什么、环境对不对”。systemd服务最常出问题的环节就在这三处，而不是脚本本身写得对不对。
查脚本自身有没有执行权限
这是第一道门槛。systemd不会帮你加x权限，没x就直接报Permission denied或Exec format error。
- 运行
ls -l /path/to/your/script.sh，看输出里有没有x（如-rwxr-xr-x） - 没有就加上：
sudo chmod +x /path/to/your/script.sh - 特别注意：用
wget、scp或编辑器直接保存的脚本，默认通常只有644权限，必须手动补x
看User和Group设得合不合理
User不是填root就万事大吉，Group也不是可有可无。它们共同划定了脚本的“活动范围”。
- 如果脚本要读
/home/user/.bashrc或调用/home/user/anaconda3/bin/python，就不能设User=root——root进不去普通用户的家目录 - 如果脚本要往
/var/www/html/写文件，只设User=www-data还不够，得确认该用户属于www-data组（groups www-data验证） - 推荐做法：新建专用用户（如
myapp），把脚本、配置、日志目录全归到它名下，再用User=myapp Group=myapp
验环境变量和路径是否可用
systemd启动时环境极简，PATH只有/usr/local/bin:/usr/bin:/bin，HOME也不一定是你想的那个。
- 脚本里别用
python main.py，改用/usr/bin/python3 /full/path/to/main.py - 需要自定义PATH或HOME？在.service文件里显式声明：
Environment="PATH=/opt/myapp/bin:/usr/local/bin:/usr/bin:/bin"Environment="HOME=/opt/myapp" - 不确定某个命令是否存在？在脚本开头加一句
which curl || exit 1，失败立刻退出，方便定位
盯住日志里的真实线索
别猜，直接看systemd记下的原始错误。
- 查服务状态：
systemctl status my_script.service，重点看Active:行和下面几行日志 - 翻完整日志：
journalctl -u my_script.service -n 50 -o cat（最近50行，纯文本格式） - 常见关键词直接对应问题：
→ No such file or directory：路径错或依赖缺失
→ Operation not permitted：权限越界（比如root写普通用户家目录）
→ Failed at step USER spawning：User指定的用户不存在或shell被禁用
