既然手动执行sudo sh /etc/rc.local能正常运行，说明你的命令逻辑本身没问题，问题大概率出在rc.local的运行环境、systemd配置或者程序依赖的前置条件上。我给你列几个最常见的排查方向：

1. 先确认rc.local的可执行权限和systemd服务状态 #

现在很多基于systemd的发行版（比如Ubuntu 16.04+、CentOS 7+），rc.local是通过rc-local.service来管理的，默认可能没启用，或者rc.local文件缺少可执行权限：

• 检查rc.local的权限：ls -l /etc/rc.local，确保它有x执行权限（比如权限显示为-rwxr-xr-x），如果没有，执行sudo chmod +x /etc/rc.local
• 检查rc-local服务状态：systemctl status rc-local.service，如果显示inactive (dead)，执行sudo systemctl enable --now rc-local.service，确保开机时系统会启动这个服务

2. 环境变量缺失的问题 #

你在终端运行程序时，有用户的完整环境变量（比如PATH、LD_LIBRARY_PATH等），但rc.local是以root身份在系统启动早期运行的，环境变量非常有限。如果你的程序依赖某个环境变量才能启动（比如需要加载特定路径的动态库，或者读取用户目录下的配置），就会启动失败：

• 解决办法：在rc.local的命令前手动设置必要的环境变量，比如如果程序依赖的库在/usr/local/lib，可以加export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH；或者确保所有依赖的命令都用绝对路径调用
• 另外，也可以先切换到程序所在的工作目录再启动，避免程序因工作目录不对找不到依赖文件：

  cd /absolute/path/to/ && /bin/sleep 30 && ./executable &
  

3. 查看rc.local的执行日志找具体错误 #

最直接的方式是查看rc-local服务的运行日志，里面会记录启动失败的具体原因：

• 执行journalctl -u rc-local.service -b，查看本次系统启动的日志（-b表示当前启动周期的日志），如果程序启动失败，这里会明确显示报错信息（比如找不到文件、权限不足、依赖缺失等）

4. 确认程序启动时机是否足够晚 #

虽然你加了/bin/sleep 30，但有些依赖（比如网络服务、硬件驱动、其他系统服务）可能需要更长时间才能就绪。你可以尝试把sleep时间延长到60秒，或者用更可靠的方式：写一个systemd服务文件来管理程序启动，通过After=配置指定程序在特定服务就绪后再运行。

举个简单的systemd服务文件示例（保存为/etc/systemd/system/myapp.service）：

[Unit]
Description=My Auto-start Application
After=network.target

[Service]
Type=simple
ExecStart=/absolute/path/to/executable
WorkingDirectory=/absolute/path/to/
User=root # 如果不需要root权限，可以改成你的用户名

[Install]
WantedBy=multi-user.target

然后启用服务：sudo systemctl enable --now myapp.service，这种方式比rc.local更可控，还能配置程序崩溃后自动重启。

内容的提问来源于stack exchange，提问作者Creative crypter