云从科技蝉联胡润中国人工智能50强
2026/1/22 5:12:35
实测Ubuntu开机自启方案，解决rc.local缺失问题
在实际使用Ubuntu系统的过程中，经常会遇到需要让某些脚本或程序在系统启动时自动运行的需求。比如部署服务、启动监控脚本、挂载设备等场景。传统上我们习惯使用/etc/rc.local来实现这一功能，但随着Ubuntu版本的演进（尤其是从16.04之后逐步转向systemd），很多用户发现rc.local要么默认不存在，要么即使存在也无法正常执行。
本文将基于真实测试环境，手把手带你实测多种可行的开机自启方案，重点解决“rc.local缺失”这一常见痛点，并提供可落地的操作建议，确保你无论使用哪个Ubuntu版本都能顺利配置开机启动脚本。
1. 问题背景：为什么rc.local会失效？
1.1 Ubuntu系统启动机制的变迁
早期Ubuntu采用SysVinit作为初始化系统，/etc/rc.local是一个标准且简单的方式，在所有服务启动完成后执行自定义命令。
但从Ubuntu 16.04开始，系统逐渐迁移到systemd架构。在这种新模式下：
rc.local不再是默认启用的服务- 即使文件存在，也需要手动激活对应的 systemd service 才能生效
- 某些最小化安装或云镜像甚至直接不包含该文件
这就导致了很多老教程失效，用户按照以往方式修改后发现脚本根本没有运行。
1.2 常见表现症状
当你尝试使用rc.local时可能会遇到以下情况：
/etc/rc.local文件不存在- 修改保存后重启无效
- 系统提示权限不足或脚本未被执行
- 日志中出现
Failed to start /etc/rc.local Compatibility错误
这说明我们必须寻找更现代、兼容性更强的替代方案。
2. 方案一：恢复并启用 rc.local（适用于仍想沿用传统方式的用户）
如果你偏好简洁写法，或者已有大量基于rc.local的脚本，可以通过以下步骤重新启用它。
2.1 创建 rc.local 文件
sudo nano /etc/rc.local填入以下内容（注意顺序和结尾exit 0）：
#!/bin/bash # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other value on error. # 添加你的命令，例如： # cd /home/user/Documents/scripts # sh auto_run_test.sh exit 0重要提示：必须以
#!/bin/bash开头，并以exit 0结尾，否则 systemd 可能拒绝执行。
2.2 设置可执行权限
sudo chmod +x /etc/rc.local2.3 启用 rc-local.service
systemd 提供了一个兼容服务单元：rc-local.service，我们需要确保其启用。
检查服务状态：
systemctl status rc-local如果显示“not-found”或“inactive”，则需创建或启用服务。
大多数情况下只需启用即可：
sudo systemctl enable rc-local.service若提示找不到服务，请先确认是否存在该 unit：
ls /lib/systemd/system/rc-local.service如果不存在，可以手动创建：
sudo nano /lib/systemd/system/rc-local.service写入如下内容：
[Unit] Description=/etc/rc.local Compatibility ConditionPathExists=/etc/rc.local [Service] Type=forking ExecStart=/etc/rc.local start TimeoutSec=0 StandardOutput=tty RemainAfterExit=yes SysVStartPriority=99 [Install] WantedBy=multi-user.target保存后再次执行：
sudo systemctl enable rc-local.service sudo systemctl start rc-local.service2.4 验证是否生效
重启系统：
sudo reboot登录后查看服务状态：
systemctl status rc-local应显示active (exited)表示成功执行。
同时验证你的脚本是否已运行（如生成了日志文件、启动了进程等）。
3. 方案二：使用 systemd 服务（推荐方式，更现代、更可靠）
对于新项目或追求稳定性的生产环境，强烈建议放弃rc.local，转而使用原生的systemd service方式。
3.1 创建自定义服务文件
假设我们要运行一个名为auto_run_test.sh的脚本。
首先创建服务定义文件：
sudo nano /etc/systemd/system/my-startup-script.service填入以下内容：
[Unit] Description=My Custom Startup Script After=network.target multi-user.target Conflicts=getty@tty1.service [Service] Type=simple User=user ExecStart=/bin/bash /home/user/Documents/scripts/auto_run_test.sh StandardOutput=journal StandardError=journal Restart=no [Install] WantedBy=multi-user.target参数说明：
After=network.target：确保网络就绪后再运行（适合依赖网络的服务）User=user：替换为实际用户名，避免权限问题ExecStart：指定脚本完整路径Restart=no：仅运行一次；若需守护进程可用alwaysWantedBy=multi-user.target：表示在多用户模式下启动
3.2 创建并授权脚本文件
mkdir -p /home/user/Documents/scripts nano /home/user/Documents/scripts/auto_run_test.sh写入测试内容：
#!/bin/bash echo "helloStartup" > /home/user/Documents/scripts/output.txt cd /home/user/mywbc_v5_usb/build || exit ./sim/sim echo "AfterSim" >> /home/user/Documents/scripts/output.txt设置可执行权限：
chmod +x /home/user/Documents/scripts/auto_run_test.sh3.3 启用并测试服务
加载服务配置：
sudo systemctl daemon-reexec sudo systemctl daemon-reload启用开机自启：
sudo systemctl enable my-startup-script.service立即启动测试（无需重启）：
sudo systemctl start my-startup-script.service查看运行状态和日志：
systemctl status my-startup-script.service journalctl -u my-startup-script.service --since "5 minutes ago"如果没有报错且输出文件生成，则说明配置成功。
3.4 优势总结
| 特性 | systemd 服务 vs rc.local |
|---|---|
| 兼容性 | 所有新版Ubuntu都支持 |
| 日志追踪 | 支持journalctl查看详细日志 |
| 执行时机控制 | 可精确控制依赖关系（如网络、GUI） |
| 错误处理 | 支持失败重试、超时、重启策略 |
| 安全性 | 可指定运行用户、资源限制 |
4. 方案三：通过 profile 或 bashrc 启动（轻量级临时方案）
当不需要严格的服务管理，只是希望每次登录时自动运行某个脚本，可以考虑修改 shell 配置文件。
4.1 追加到 /etc/profile（所有用户登录时执行）
sudo nano /etc/profile在文件末尾添加：
if [ -f /home/user/Documents/scripts/auto_run_test.sh ]; then /bin/bash /home/user/Documents/scripts/auto_run_test.sh fi这种方式的特点是：
- 每次用户登录终端时都会执行
- 包括SSH远程登录、图形界面打开终端等情况
- 不适用于无人值守服务器（因为需要“登录”触发）
4.2 追加到 ~/.bashrc（仅当前用户）
nano ~/.bashrc末尾加入：
# 自启动脚本 /home/user/Documents/scripts/auto_run_test.sh注意：这种方式会在每次打开新终端窗口时重复执行，不适合只运行一次的任务。
4.3 使用场景建议
| 场景 | 推荐方式 |
|---|---|
| 图形界面登录后自动启动应用 | .xprofile或桌面自动启动项 |
| SSH登录后初始化环境 | ~/.bashrc或/etc/profile |
| 无人值守后台服务 | systemd service（首选） |
| 快速调试小脚本 | profile 临时添加 |
5. 实际案例对比测试结果
为了验证各方案的实际效果，我们在 Ubuntu 20.04 LTS 环境下进行了实测：
| 方案 | 是否成功 | 执行时间点 | 是否需要登录 | 日志是否可查 | 推荐指数 |
|---|---|---|---|---|---|
| 恢复 rc.local | 成功（需手动启用服务） | 系统启动后期 | 否 | ❌ 难追踪 | ★★★☆☆ |
| systemd 服务 | 成功 | 可控（如网络就绪后） | 否 | journalctl | ★★★★★ |
| /etc/profile | 成功 | 用户登录时 | 是 | 终端可见 | ★★☆☆☆ |
| ~/.bashrc | 成功但重复执行 | 每开终端一次 | 是 | ★☆☆☆☆ |
结论：systemd 是目前最可靠、最灵活的方案，尤其适合自动化部署和服务器环境。
6. 常见问题与避坑指南
6.1 脚本路径必须使用绝对路径
无论是rc.local还是 systemd，都不要使用相对路径：
❌ 错误写法：
sh auto_run_test.sh正确写法：
/bin/bash /home/user/Documents/scripts/auto_run_test.sh6.2 注意用户权限问题
脚本中涉及文件操作时，务必确认运行用户是否有权限访问目标目录。
例如：/home/user/...目录普通用户可写，但如果是root运行则可能无权写入。
解决方案：在 systemd 中明确指定User=yourusername
6.3 环境变量缺失问题
systemd 启动的服务不会自动加载用户的.bashrc或.profile，因此环境变量（如PATH、ROS_PACKAGE_PATH等）可能缺失。
解决方法：
- 在脚本开头显式导出所需变量：
export PATH=/usr/local/bin:$PATH export MY_APP_HOME=/opt/myapp- 或者在 service 文件中添加：
[Service] Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"6.4 如何调试启动失败？
使用以下命令排查：
# 查看服务状态 systemctl status your-service-name # 查看日志 journalctl -u your-service-name.service -b # 手动运行脚本测试 sudo -u user /bin/bash /path/to/script.sh7. 总结
在现代Ubuntu系统中，传统的rc.local已不再是开箱即用的解决方案。面对“rc.local缺失”的问题，我们不应强行回退旧模式，而应顺势拥抱更强大的 systemd 服务体系。
本文实测了三种主流方案：
- 恢复 rc.local：适合已有脚本迁移，但需额外配置服务单元；
- systemd 服务：推荐方式，稳定性高、可控性强、日志完善；
- profile/baschrc 注入：适合登录级任务，不适合后台常驻服务。
最终建议：
对于任何需要“开机自动运行”的任务，优先选择systemd 自定义服务方式。它不仅兼容性好，而且具备完善的生命周期管理和故障诊断能力，是当前Linux系统的最佳实践。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。