再也不用手动跑脚本了，测试开机启动脚本真香体验
你有没有过这样的经历：每次开机后第一件事就是打开终端，cd到桌面，再敲一遍./test.sh？明明只是想让一个简单的检测脚本自动运行，却要重复操作好几遍。更别提遇到工控机、服务器或者无人值守设备时，没人手动点开终端，脚本就永远躺在那里“睡大觉”。
今天这篇文章不讲高深理论，不堆砌术语，就用最实在的方式，带你把test.sh这个小脚本真正变成开机就能自己干活的“数字员工”。我们不搞虚的，只聊三种在Ubuntu系统上真正能落地、能验证、出问题好排查的方法——从传统可靠到现代灵活，每一种都配了可直接复制粘贴的命令，还有我踩过的坑和绕过的弯。
全文所有操作都在标准Ubuntu 20.04/22.04环境下实测通过，不需要额外安装软件，不依赖图形界面是否就绪，也不要求你成为Linux专家。只要你能打开终端、会复制粘贴，就能搞定。
1. 最稳当的老办法：放进/etc/init.d目录（适合服务类脚本）
这是Linux系统最经典、兼容性最强的开机自启方式，尤其适合那些需要在系统服务层级就运行的脚本——比如检测硬件状态、挂载设备、启动后台守护进程等。它不依赖用户登录，哪怕你没输密码进桌面，它也会默默执行。
1.1 脚本准备：先让它“守规矩”
系统对/etc/init.d里的脚本有基本要求：必须有可执行权限，最好带标准的shell shebang头，且逻辑清晰。我们拿你的test.sh稍作优化：
#!/bin/bash # /home/User/Desktop/test.sh # 开机自启测试脚本 —— 简洁、明确、易排查 # 切换到目标目录（注意：这里用绝对路径，避免环境变量干扰） cd /home/User/Desktop || { echo "ERROR: 无法进入 /home/User/Desktop 目录" >&2 exit 1 } # 执行核心操作 ls -la echo " test.sh 已成功执行于 $(date)" >> /home/User/Desktop/startup_log.txt exit 0小提醒：把
User替换成你真实的用户名（比如ubuntu或john），否则脚本会找不到路径。>>追加日志是排查问题的关键，建议保留。
1.2 放入系统服务目录并注册
打开终端，按顺序执行（每行一条，别跳）：
# 1. 把脚本复制到系统服务目录（需要sudo） sudo cp /home/User/Desktop/test.sh /etc/init.d/test-startup # 2. 赋予可执行权限（755比777更安全，普通用户不可写） sudo chmod 755 /etc/init.d/test-startup # 3. 注册为默认启动项（系统会自动创建软链接到各运行级别） sudo update-rc.d test-startup defaults执行完第三步，你会看到类似提示：
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults Adding system startup for /etc/init.d/test-startup ...这属于正常提示，不用管。它表示脚本已成功注册。
1.3 验证与调试：别急着重启，先本地试
在重启前，务必本地验证脚本能否独立运行：
# 模拟系统启动时的调用方式 sudo /etc/init.d/test-startup start如果终端输出了文件列表，并且你在桌面看到了startup_log.txt，说明脚本本身没问题。
常见卡点：
- 路径错误：
cd /home/User/Desktop中的User必须是你真实用户名；- 权限不足：确保
/home/User/Desktop目录对root用户可读（ls -ld /home/User/Desktop查看）；- 日志无内容？检查
startup_log.txt是否被写入，这是判断脚本是否真执行的唯一证据。
2. 最直观的桌面法：用 GNOME 启动应用程序（适合图形界面场景）
如果你的设备是带桌面的Ubuntu（比如开发机、演示机、工控触摸屏），而且脚本最终目的是和用户交互（比如弹窗、打开GUI工具、启动监控面板），那么这种方法最友好——它在你登录进桌面后才触发，环境完整，路径、显示、声音全都有。
2.1 图形化配置：三步添加，所见即所得
- 打开终端，输入以下命令启动“启动应用程序”管理器：
gnome-session-properties - 点击左下角的+ 添加按钮；
- 在弹出窗口中填写：
- 名称：
Test Startup Script - 命令：
gnome-terminal -- bash -c "/home/User/Desktop/test.sh; exec bash" - 注释：
运行开机检测脚本并保持终端开启
- 名称：
为什么命令这么写？
gnome-terminal -- bash -c "..."是标准启动方式；exec bash是关键——它让终端窗口不会执行完就关闭，方便你一眼看到输出结果；
如果你希望终端静默运行（不弹窗），就把命令换成：bash /home/User/Desktop/test.sh > /home/User/Desktop/log.txt 2>&1 &
2.2 无GUI？试试.bashrc间接法（轻量级备选）
如果你不想多开一个终端窗口，又确定脚本只在你登录后才需要运行，可以把它“藏”进你的shell初始化文件里：
# 编辑 ~/.bashrc（用你习惯的编辑器，如 nano 或 gedit） nano ~/.bashrc在文件最末尾添加一行：
# 开机自动运行测试脚本（仅限当前用户登录时） [ -f "/home/User/Desktop/test.sh" ] && bash /home/User/Desktop/test.sh >> /home/User/Desktop/bashrc_log.txt 2>&1保存退出后，执行source ~/.bashrc立即生效。下次你打开新终端，脚本就会自动跑一次。
优势：无需sudo，纯用户级，删掉那行就失效，零风险。
注意：.bashrc只在交互式非登录shell（比如新开终端）中读取，不是严格意义上的“开机启动”，但对日常开发场景足够实用。
3. 最简洁的通用法：修改rc.local（适合快速验证）
rc.local是系统启动流程中最后一个“兜底”环节，它在几乎所有服务启动完毕后、用户登录前执行。它的优势是：写法极简、位置固定、逻辑清晰，特别适合一次性验证脚本逻辑是否能在纯系统环境下跑通。
3.1 编辑 rc.local 文件（需 root 权限）
# 编辑文件（如果不存在，会自动创建） sudo nano /etc/rc.local将内容改为如下（注意保留原有注释头，exit 0必须在最后一行）：
#!/bin/sh -e # # 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. # # In order to enable or disable this script, simply change the execution # bits (chmod +x /etc/rc.local). # # 下面是你自己的命令 cd /home/User/Desktop && ./test.sh >> /var/log/test-startup.log 2>&1 exit 03.2 关键一步：赋予可执行权限
很多教程漏掉这步，导致rc.local完全不执行！请务必执行：
sudo chmod +x /etc/rc.local3.3 验证是否生效：别等重启，用命令模拟
# 手动触发 rc.local 执行（效果等同于开机） sudo /etc/rc.local # 然后检查日志 sudo tail -n 5 /var/log/test-startup.log如果看到时间戳和ls输出，说明一切就绪。
🧩 补充说明：Ubuntu 18.04+ 默认使用 systemd，
rc.local兼容性靠systemd-sysv-generator自动处理。只要文件存在、有执行权限、以#!/bin/sh -e开头、结尾是exit 0，它就一定会被调用。
4. 方法对比与选型建议：哪种更适合你？
面对三种方案，新手常纠结“该选哪个”。其实没有标准答案，只有“最适合当前场景”的选择。下面这张表，帮你一眼看清差异：
| 维度 | /etc/init.d方式 | GNOME 启动应用 | rc.local方式 |
|---|---|---|---|
| 触发时机 | 系统服务启动阶段（早于用户登录） | 用户登录桌面后（图形环境就绪） | 所有系统服务启动完毕后（晚于网络就绪） |
| 是否需要图形界面 | 完全不需要 | 必须有GNOME桌面 | 完全不需要 |
| 适用脚本类型 | 后台服务、硬件检测、网络配置 | GUI交互、弹窗通知、桌面工具启动 | 通用任务、环境检查、日志归档 |
| 调试难度 | 中（需查/var/log/syslog） | 低（终端可见、日志直出） | 低（日志路径固定，tail -f实时看） |
| 权限要求 | 需要sudo | 仅当前用户权限 | 需要sudo |
| 推荐指数 | ☆（稳定首选） | （桌面用户首选） | （快速验证首选） |
我的真实建议：
- 如果是工控机、服务器、无人值守设备→ 优先用
/etc/init.d或rc.local，确保无桌面也能工作； - 如果是个人开发机、教学演示机、带触摸屏的展示终端→ 用 GNOME 启动应用，省心、直观、易维护；
- 如果只是临时验证脚本逻辑、赶时间交差、不想动太多配置→
rc.local一气呵成，5分钟搞定。
5. 故障排查锦囊：90%的问题，这四步就能定位
再完美的教程也架不住环境千差万别。以下是我在上百次部署中总结出的“黄金四步排查法”，专治各种“为啥没执行”：
5.1 第一步：确认脚本本身能跑通
# 切换到脚本所在目录 cd /home/User/Desktop # 用和开机时完全相同的用户身份运行（比如root或你自己的用户） sudo bash test.sh # 或者直接 bash test.sh # 成功标志：有预期输出，且日志文件有内容5.2 第二步：检查路径和权限
# 确认脚本路径拼写100%正确（大小写、空格、用户名） ls -l /home/User/Desktop/test.sh # 输出应类似：-rwxr-xr-x 1 User User ... test.sh # 确认目标目录可被访问 ls -ld /home/User/Desktop # 输出中应有 `drwxr-xr-x` 或类似，且第三列是你的用户名5.3 第三步：查看对应日志
/etc/init.d方式 → 查sudo journalctl -u test-startup或sudo grep test /var/log/syslog- GNOME 方式 → 查你指定的日志文件（如
~/Desktop/log.txt） rc.local方式 → 查sudo cat /var/log/test-startup.log或sudo journalctl -u rc-local
5.4 第四步：终极验证——手动模拟启动流程
# 对 init.d：模拟系统调用 sudo /etc/init.d/test-startup start # 对 rc.local：直接执行 sudo /etc/rc.local # 对 GNOME：手动运行命令 gnome-terminal -- bash -c "/home/User/Desktop/test.sh; exec bash"只要其中任何一个能成功，说明脚本没问题，问题一定出在“注册”或“触发”环节。
6. 总结：让脚本真正“活”起来，才是自动化的核心
到这里，你已经掌握了三种在Ubuntu上让test.sh开机自启的完整路径。它们不是冰冷的命令集合，而是三种不同哲学：
/etc/init.d代表系统级的严谨——它把脚本当作一个正式服务来对待；- GNOME 启动应用代表用户级的友好——它把脚本当作你桌面工作流的一部分；
rc.local代表工程级的务实——它不挑环境，只求结果，是快速落地的利器。
真正的自动化，从来不是“写完脚本就结束”，而是“让脚本在正确的时间、以正确的身份、做正确的事”。你不需要记住所有参数，只需要记住：有日志、能验证、分场景、敢动手。
现在，关掉这篇博客，打开你的终端，选一种方法，亲手试一次。五分钟后，当你重启电脑，看到终端自动弹出、日志文件静静生成，那种“终于不用再手动敲了”的轻松感，就是技术带给我们的最朴素的快乐。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
