开机启动脚本不执行通常因执行环境、权限或时机问题，需按“是否被调用→查日志→排查路径/环境变量/依赖→核对权限”顺序逐层验证，而非修改脚本逻辑。
开机启动脚本不执行，通常不是脚本本身写错了，而是执行环境、权限或时机出了问题。排查要从“它有没有被调用”开始，一层层往下验证，而不是反复改脚本逻辑。
先确认脚本是否被系统识别并启用
不同机制启用方式不同，必须对号入座：
- 如果是 systemd 服务（推荐方式）：运行 sudo systemctl is-enabled your-service.service，返回 enabled 才算真正启用；返回 disabled 或报错，说明没生效
- 如果是 /etc/rc.local：检查 systemctl status rc-local，状态必须是 active (exited)；若为 inactive 或 failed，代表 rc-local 服务根本没跑起来
- 如果是 /etc/init.d/ 脚本：运行 ls /etc/rc?.d/ | grep your-script，看到类似 S99your-script 的软链接才算已注册到对应运行级
看日志——最直接的证据来源
别猜，直接查系统记录了什么：
- systemd 服务：用 sudo journalctl -u your-service.service -b 查本次启动的日志；加 -n 50 只看最新50行，避免刷屏
- rc.local 执行过程：日志默认走系统总日志，运行 sudo journalctl -b | grep -i "rc.local\|rc-local"
- 通用方法：在脚本开头加一句 date >> /tmp/boot_debug.log 2>&1，重启后看这个文件有没有时间戳——有，说明脚本被调用了；没有，说明压根没走到这一步
重点检查三个“静默杀手”
它们不会报明显错误，但会让脚本一启动就退出：
- 路径和命令全是相对的：rc.local 和 systemd 服务默认工作目录是 /，cd Desktop 必然失败；所有路径必须写绝对路径，比如 /home/username/Desktop/myscript.sh
- 环境变量完全缺失：PATH 可能只有 /bin:/sbin，你写的 python3 或 conda 根本找不到；要么用绝对路径（如 /usr/bin/python3），要么在脚本里显式设置 PATH
- 依赖条件未满足就执行：比如脚本要访问网络或挂载硬盘，但 After=network.target 没写，或 rc.local 在网卡驱动加载前就跑了；可加 sleep 5 简单延时测试，再逐步优化依赖声明
权限和归属必须匹配执行身份
脚本能不能跑，不只看它自己，还要看谁在跑它：
- systemd 默认以 root 运行，如果你的脚本要读 /home/user/.bashrc 或写入 /home/user/logs/，root 没权限访问普通用户家目录——要么改 User=user，要么把相关文件设为 group 可读、并把 root 加入该组
- 脚本文件本身必须有 x 权限：ls -l /path/to/script.sh 输出中要有 rwx；没的话立刻补上：sudo chmod +x /path/to/script.sh
- 如果脚本里调用了其他程序（如 ffmpeg、node），也要确认这些程序对当前执行用户是可访问的
