rc.local 经常不生效是因为现代 linux 发行版默认使用 systemd，rc-local 服务被屏蔽或未启用；需检查状态、确保文件可执行且含正确 shebang、用绝对路径调用命令和 python 解释器、避免交互操作；更可靠的方式是改用 systemd service，并正确配置依赖、启动时机和日志排查。
rc.local 为什么经常不生效
因为多数现代 Linux 发行版（Ubuntu 16.04+、CentOS 7+、Debian 9+）默认用 systemd 管理启动流程，/etc/rc.local 不再自动启用，甚至服务单元被屏蔽（masked）。你加了脚本却没运行，大概率不是写错了，而是 rc-local 服务根本没启动。
实操建议：
- 先检查服务状态：
systemctl status rc-local—— 如果显示inactive (dead)或masked，就得手动启用 - 确保
/etc/rc.local文件存在且可执行：chmod +x /etc/rc.local - 确认文件以正确 shebang 开头（如
#!/bin/bash），且第一行不是空行或注释（systemd会跳过无 shebang 的脚本） - 在
/etc/rc.local里所有命令前加完整路径（比如用/usr/bin/python3而非python3），因为开机时$PATH极简
rc.local 里执行 Python 脚本总失败
常见错误现象是日志里报 ModuleNotFoundError 或直接卡住不动 —— 不是 Python 没装，而是环境没加载。开机时 rc.local 以 root 身份、极简 shell（通常是 /bin/sh）运行，不读取用户 .bashrc 或 venv 激活逻辑。
实操建议：
- 用绝对路径调用解释器和脚本：
/usr/bin/python3 /opt/myscript.py - 如果依赖虚拟环境，别用
source venv/bin/activate—— 改为直接调用环境里的 python：/opt/myproject/venv/bin/python /opt/myproject/main.py - 重定向输出查错：
/usr/bin/python3 /opt/myscript.py >> /var/log/myscript.log 2>&1 - 避免交互式操作（如
input()、getpass()），开机时没有 stdin
systemd 替代方案更可靠但容易配错
如果你发现 rc.local 总不稳定，直接写 systemd service 是更现代、更可控的选择。但它对路径、权限、依赖顺序敏感，配错就静默失败。
实操建议：
- 服务文件必须放在
/etc/systemd/system/下，后缀为.service（如myscript.service） -
Type=oneshot适合只运行一次的脚本；加RemainAfterExit=yes才能让 systemd 认为服务“成功运行”而非立即退出 - 用
WantedBy=multi-user.target（不是default.target），否则可能错过网络就绪时机 - 务必运行
systemctl daemon-reload，否则修改不生效；然后用systemctl enable myscript.service启用 - 查错看日志：
journalctl -u myscript.service -b
脚本执行时机比你想的更早
无论走 rc.local 还是 systemd，脚本都在网络、挂载、用户服务之前运行。如果你的脚本要访问 NFS 目录、调用 curl 请求内网 API、或依赖 dockerd，十有八九会失败 —— 它们还没起来。
实操建议：
- 加等待逻辑不如加依赖声明：在 systemd service 里用
After=network-online.target和Wants=network-online.target - 对 NFS 或远程存储，用
systemd.mount单元确保挂载完成后再启动你的服务 - 避免在脚本里硬写
sleep 30，不可靠还拖慢启动；优先用systemd的依赖机制 - 如果必须等某个进程（如
docker），可用ExecStartPre=/bin/sh -c 'until command -v docker &>/dev/null; do sleep 1; done'，但仅作兜底
真正麻烦的从来不是“怎么加一行命令”，而是搞清它在哪一刻、以什么身份、带着什么环境、面对什么依赖去执行 —— 这些细节不核对清楚，重启后脚本不跑，连日志都找不到地方看。
