开机自动执行脚本的正确姿势，测试脚本亲测可用
在日常使用 Linux 系统的过程中，我们常常会遇到需要让某些任务在系统启动时自动运行的需求。比如：启动监控服务、挂载网络磁盘、初始化环境变量，或者像本文中的简单测试脚本。如何安全、稳定、可靠地实现“开机自动执行脚本”，是每个运维人员和开发者都应掌握的基础技能。
本文将围绕一个经过实际验证的测试脚本，详细介绍几种主流且有效的 Ubuntu 开机自启方案，并结合真实操作步骤、注意事项和常见问题，帮助你选择最适合当前场景的方法。所有方法均已在标准 Ubuntu 桌面环境中实测通过。
1. 测试脚本准备与验证
在配置任何开机启动机制之前，首先要确保你的脚本本身是可以正常运行的。以下是一个简单的测试脚本，用于验证是否成功执行。
1.1 创建测试脚本
#!/bin/bash # test.sh - 简单的开机启动测试脚本 cd /home/Desktop/ ls echo "OK!" >> /home/Desktop/boot_test.log exit 0说明：
- 脚本会进入桌面目录并列出文件。
- 同时向
boot_test.log写入一行标记信息，便于重启后确认是否执行。- 使用绝对路径更稳妥（如
/bin/ls），但此处为简化示例保留相对调用。
保存为test.sh，建议放在用户主目录或 Desktop 下方便调试：
nano ~/Desktop/test.sh1.2 设置可执行权限
chmod +x ~/Desktop/test.sh1.3 手动运行测试
~/Desktop/test.sh检查桌面是否生成了boot_test.log文件，并包含"OK!"内容。若能正常运行，则可以继续下一步配置开机启动。
2. 方法一：使用 /etc/init.d + update-rc.d（传统 SysVinit 方式）
这是较早版本 Ubuntu 中广泛使用的开机启动方式，基于 SysVinit 初始化系统。虽然现代 Ubuntu 已转向 systemd，但该方法仍可通过兼容层支持。
2.1 将脚本移至 init.d 目录
sudo mv ~/Desktop/test.sh /etc/init.d/2.2 添加执行权限
sudo chmod 755 /etc/init.d/test.sh建议不要使用
777，出于安全考虑，仅赋予必要权限即可。
2.3 注册为开机服务
sudo update-rc.d test.sh defaults这会在各个运行级别（runlevel）下创建相应的符号链接，使脚本在系统启动和关闭时按默认顺序执行。
自定义启动优先级
如果你希望控制脚本的执行时机（例如晚于网络服务），可以指定启动序号：
sudo update-rc.d test.sh defaults 99数字越大，启动越晚。一般服务范围在 20~99 之间。
2.4 移除开机注册
如果后续不再需要此脚本开机运行：
sudo update-rc.d -f test.sh remove
-f表示强制删除相关链接。
2.5 注意事项
- 此方法适用于仍使用 SysVinit 或兼容模式的系统。
- 脚本执行时可能尚未加载图形界面或用户会话，因此涉及 GUI 操作（如弹窗、访问桌面）可能会失败。
- 推荐用于后台服务类任务，而非依赖桌面环境的操作。
3. 方法二：通过 GNOME 启动应用程序（图形化桌面自启）
对于桌面用户来说，最直观的方式是利用 GNOME 提供的“启动应用程序”功能，在用户登录后自动执行命令或脚本。
3.1 使用 gnome-session-properties 图形工具
打开终端，输入：
gnome-session-properties这将弹出“启动应用程序首选项”窗口。
3.2 添加新启动项
点击“添加”按钮，填写以下内容：
- 名称：Test Script
- 命令：
gnome-terminal -- bash -c "/home/$USER/Desktop/test.sh; exec bash" - 注释：运行开机测试脚本
$USER会自动替换为当前用户名，也可手动写死路径。
关键点解释：
gnome-terminal -- bash -c "..."：打开一个终端窗口并执行命令。exec bash：防止终端立即关闭，便于查看输出结果（调试阶段推荐保留）。- 若不需显示终端，可改为直接调用脚本：
/home/$USER/Desktop/test.sh
3.3 间接方式：修改 .bashrc（慎用）
有些文章建议将命令写入~/.bashrc，这样每次打开终端都会执行。但这并不等于“开机自启”，仅当用户主动打开终端时才触发。
echo "/home/$USER/Desktop/test.sh" >> ~/.bashrc❌ 不推荐作为开机启动手段，容易造成重复执行或误判。
3.4 适用场景总结
| 特性 | 是否支持 |
|---|---|
| 用户登录后执行 | |
| 支持图形界面操作 | |
| 需要用户交互 | （可选） |
| 适合桌面自动化 | |
| 服务器无界面环境 | ❌ |
提示：若使用工控机或无人值守设备，建议设置自动登录，否则脚本不会触发。
4. 方法三：rc.local 方案（经典通用法）
/etc/rc.local是一个传统的系统级启动脚本，在大多数 Linux 发行版中都存在。它在系统初始化接近完成时执行，通常在多用户模式启动前。
4.1 编辑 rc.local 文件
sudo nano /etc/rc.local确保文件以exit 0结尾，并在其上方插入你要执行的命令：
#!/bin/sh -e # # rc.local # # 添加你的脚本调用 su - $USER -c "/home/$USER/Desktop/test.sh" exit 0解释：
su - $USER -c：切换到指定用户执行命令，避免因 root 权限导致无法访问用户目录。- 必须保证
/etc/rc.local本身具有执行权限。
4.2 设置 rc.local 可执行
Ubuntu 默认可能未启用rc.local兼容服务，需手动激活：
sudo chmod +x /etc/rc.local创建 systemd 服务单元文件（如果不存在）：
sudo nano /etc/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 sudo systemctl start rc-local4.3 验证服务状态
sudo systemctl status rc-local查看日志排查问题：
journalctl -u rc-local.service4.4 优缺点分析
| 优点 | 缺点 |
|---|---|
| 兼容性强，几乎所有 Linux 都支持 | 执行时间早于用户登录，可能无法访问桌面路径 |
| 易于理解和维护 | 需要额外配置 systemd 单元才能生效（Ubuntu 18.04+） |
| 适合系统级初始化任务 | 若脚本阻塞，会影响开机流程 |
5. 方法四：使用 systemd 用户服务（现代推荐做法）
systemd 是当前 Linux 主流的初始化系统，其服务管理机制更加灵活、强大。推荐高级用户采用此方式实现精细化控制。
5.1 创建用户级 service 文件
mkdir -p ~/.config/systemd/user/ nano ~/.config/systemd/user/test-script.service写入以下内容：
[Unit] Description=Run Test Script at Boot After=graphical-session.target [Service] Type=oneshot ExecStart=/home/%u/Desktop/test.sh RemainAfterExit=yes [Install] WantedBy=default.target
%u表示当前用户，等价于$USER。
5.2 启用并启动服务
# 启用开机自启 systemctl --user enable test-script.service # 立即运行一次（无需重启） systemctl --user start test-script.service # 查看状态 systemctl --user status test-script.service5.3 允许用户服务随系统启动（关键一步）
默认情况下，用户服务不会在开机时自动激活，除非启用了 linger 功能：
sudo loginctl enable-linger $USER这允许用户的 systemd 用户实例在未登录时也运行，是实现“开机自启”的前提。
5.4 优势总结
| 特性 | 说明 |
|---|---|
| 精确控制启动时机 | 可设置依赖关系（如等待桌面就绪） |
| 日志集中管理 | 使用journalctl --user -u test-script.service查看输出 |
| 安全性高 | 以用户身份运行，避免滥用 root 权限 |
| 支持复杂逻辑 | 支持定时、重试、超时等高级特性 |
推荐用于生产环境或对稳定性要求较高的场景。
6. 各方法对比与选型建议
为了帮助你快速决策，以下是四种主要方法的综合对比：
| 方法 | 执行时机 | 是否需要图形界面 | 权限模型 | 适用场景 | 推荐指数 |
|---|---|---|---|---|---|
/etc/init.d + update-rc.d | 系统启动早期 | 否 | root 或脚本自身 | 传统服务迁移 | ☆ |
GNOME 启动应用程序 | 用户登录后 | 是 | 当前用户 | 桌面自动化、GUI 工具 | |
rc.local | 系统启动末期 | 否（但可切用户） | root（需切换） | 简单系统初始化 | |
systemd user service | 登录前后（开启 linger） | 可控 | 当前用户 | 现代化、长期运行任务 |
选择建议：
- 普通桌面用户：优先使用GNOME 启动应用程序，简单直观。
- 需要后台静默运行：推荐systemd 用户服务，配合
loginctl enable-linger实现真正意义上的“开机即运行”。 - 遗留系统兼容需求：可使用
/etc/init.d或rc.local。 - 避免使用
.bashrc注入方式：不可靠，易引发副作用。
7. 常见问题与排错技巧
7.1 脚本没有执行？
- 检查是否设置了可执行权限：
ls -l test.sh - 查看目标路径是否存在，特别是
Desktop在不同语言环境下可能是桌面。 - 使用绝对路径代替相对路径（如
/bin/ls,/usr/bin/echo）。
7.2 日志文件未生成？
- 确保目标目录有写权限。
- 如果是 root 执行，
/home/$USER/Desktop/可能不可写，务必使用su - $USER -c切换用户。
7.3 终端一闪而过？
- 在命令末尾加上
read -p "Press Enter to continue..."或使用gnome-terminal -- bash -c "script; exec bash"保持终端打开。
7.4 如何查看执行日志？
对于 systemd 用户服务：
journalctl --user -u test-script.service对于 rc.local：
journalctl -u rc-local.service可在脚本中增加日志输出：
exec >> /tmp/boot_script.log 2>&1 echo "[$(date)] Starting script..."
8. 总结
本文详细介绍了四种在 Ubuntu 系统中实现开机自动执行脚本的方法，每种都有其适用场景和技术特点：
/etc/init.d+update-rc.d：传统方式，适合老系统维护；- GNOME 启动应用程序：最友好的桌面用户方案，适合日常使用；
rc.local：经典通用入口，需注意权限和执行时机；- systemd 用户服务：现代 Linux 的最佳实践，推荐作为首选方案。
无论你是在做嵌入式开发、自动化部署，还是仅仅想让某个小工具随系统启动，都可以根据实际需求选择最合适的方式。关键是：先测试脚本、再配置启动、最后验证效果。
只要遵循本文提供的步骤和建议，你的脚本就能稳稳当当地在每次开机时自动运行。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
