rc.local 开机脚本sleep会阻塞系统启动

少于 1 分钟阅读次阅读

分析

rc.local 运行的性质：
- 尽管不同发行版和 systemd 的实现细节可能略有差异，rc.local 通常是在系统启动接近完成时（例如在 multi-user.target 阶段），由 rc-local.service 或类似的服务同步执行的一个脚本。
- 这意味着整个启动序列（由 systemd 管理）在运行 rc.local 时，会等待这个脚本中的所有命令按顺序执行完毕，才会最终标志该启动阶段（rc-local.service 或依赖它的目标）为“完成”(active)。
sleep 命令的作用：
- sleep [seconds] 命令会让执行它的进程（在这里是整个 rc.local 脚本进程）暂停执行指定的秒数。
- 在 sleep 执行期间，rc.local 脚本不会执行下一条指令，整个脚本进程处于等待状态。
systemd 的行为：
- systemd 在启动服务时（如 rc-local.service），默认会等待这个服务完全结束才继续后续的启动步骤或标记目标为完成。
- 如果 rc.local 脚本中包含 sleep 30，那么 rc-local.service 就需要至少 30 秒额外的时间才能完成启动（除了脚本本身其他命令执行的时间）。
- 由于 rc.local 通常是启动序列的最后一步（用于运行一些自定义命令），阻塞它就等同于阻塞了启动序列的最终完成。

启动时间延长：整个系统的启动时间会增加。增加的时间就是 sleep 命令指定的秒数。
启动“卡住”的感觉：如果你在物理机或虚拟机上看到启动文本或图形界面的进度条/日志，在 rc.local 开始执行且遇到 sleep 时，会明显停顿住，直到 sleep 结束。

更好的做法通常是避免在 rc.local 中使用 sleep，而是使用更精准的依赖管理：

使用 systemd 的依赖关系：
- 将你的自定义任务写成一个独立的 systemd 服务单元文件(.service)，而不是放在 rc.local 里。
- 在这个服务文件中，使用 After=, Requires=, Wants= 等指令明确声明它需要等待哪些特定的服务或设备（如 network-online.target, your-hardware-device.service）启动完成后再运行自己。这样 systemd 会负责调度，你的脚本无需 sleep 猜测。
使用 systemd 的计时器(.timer)：
- 如果你想在启动后一段时间运行某个任务，创建一个计时器单元(.timer)来触发你的服务单元(.service)。计时器可以设置为在启动后的特定时间（如 OnBootSec=1min）运行。
轮询或事件监听：
- 在脚本中使用循环加短暂 sleep (如 sleep 1 或 sleep 0.5) 并检查条件（如检查文件是否存在、检查特定 systemctl is-active 状态、检查网络连接 ping -c1 -W1 google.com > /dev/null），一旦条件满足立即退出循环并执行任务。这比单一的、可能过长或过短的 sleep 更可靠和高效。不过也要注意避免无限循环。