从0开始配置Ubuntu开机启动项，超详细图文教程
你是不是也遇到过这样的问题：写好了自动化脚本，想让它每次开机就自动运行，却卡在“怎么加进系统启动流程”这一步？试过网上各种方法，结果不是没生效，就是重启后系统直接进不去？别急，这篇教程就是为你量身定制的——不讲虚的，不跳步骤，不假设你懂Linux底层，只用最直白的语言、最贴近真实操作的截图逻辑（文字还原版）、最稳妥的实操路径，带你从零完成Ubuntu开机启动项配置。
本文以一个真实可用的测试脚本为线索，完整覆盖：脚本创建 → 权限设置 → 启动机制选择 → 配置文件修改 → 效果验证 → 常见故障排查。所有操作均在Ubuntu 22.04 LTS（桌面版）实测通过，兼容18.04/20.04/24.04等主流版本。即使你是第一次打开终端的新手，也能照着一步步走通。
1. 先搞清楚：Ubuntu开机启动到底有几种方式？
很多教程一上来就让你改rc.local，但没告诉你——这个文件在新版Ubuntu里默认根本不存在。盲目操作不仅无效，还可能破坏系统稳定性。我们先理清思路，再动手：
rc.local方式：传统、简单、适合单用户轻量任务，但需手动启用服务，且Ubuntu 20.04+默认禁用- systemd服务方式：现代标准、稳定可靠、支持日志查看和状态管理，推荐用于生产环境
/etc/profile追加方式：仅对登录用户生效，且只在图形界面或终端登录时触发，不是真正意义上的“开机启动”（系统服务未启动前它不会运行）
本文主推systemd服务方式（安全、可控、可查），同时保留
rc.local作为备选方案，并明确说明何时该用哪一种。你不需要记住所有原理，只要知道：“想让脚本在系统一通电就跑 → 用systemd；只想让它在你点开桌面后自动执行 →/etc/profile够用”。
2. 创建你的第一个开机启动脚本
我们不用虚构例子，就用你提供的auto_run_test.sh作为起点，但会优化它，让它更健壮、更易调试。
2.1 选择存放位置与创建脚本
建议将脚本统一放在/opt/scripts/目录下（这是Linux中存放第三方脚本的标准位置，比/home/user/Documents/scripts更规范，且不受用户家目录权限影响）：
# 创建目录（如果不存在） sudo mkdir -p /opt/scripts # 进入目录 cd /opt/scripts # 创建脚本文件 sudo nano auto_run_test.sh小贴士：这里用
nano而不是vim，因为nano对新手更友好（底部有操作提示，按Ctrl+O保存，Ctrl+X退出）。如果你习惯vim，当然也可以用。
在编辑器中输入以下内容（已修正原示例中的常见错误，如中文引号、路径硬编码、缺少错误处理）：
#!/bin/bash # 设置日志路径，方便后续排查 LOG_FILE="/var/log/auto_run_test.log" echo "[$(date)] Script started" >> "$LOG_FILE" # 确保进入正确工作目录（使用绝对路径，避免依赖当前shell环境） cd /opt/scripts || { echo "[$(date)] Failed to cd to /opt/scripts" >> "$LOG_FILE"; exit 1; } # 模拟你要做的实际任务：写入测试内容 echo "helloStartup $(date)" > ./output.txt echo "[$(date)] Wrote to output.txt" >> "$LOG_FILE" # 如果你有其他程序要运行（比如你的sim程序），请取消下面两行的注释，并修改路径 # cd /home/user/mywbc_v5_usb/build || { echo "[$(date)] Failed to cd to build dir" >> "$LOG_FILE"; exit 1; } # ./sim/sim >> "$LOG_FILE" 2>&1 echo "[$(date)] Script finished successfully" >> "$LOG_FILE"2.2 设置脚本执行权限
脚本创建完成后，必须赋予它“可执行”权限，否则系统无法运行它：
sudo chmod +x /opt/scripts/auto_run_test.sh注意：不要用
chmod 777！这是严重安全隐患。+x表示“添加执行权限”，足够且安全。777意味着任何人（包括恶意程序）都能读、写、执行这个文件，完全没必要。
2.3 测试脚本能否独立运行
在加入开机启动前，务必先手动运行一次，确认它本身没问题：
sudo /opt/scripts/auto_run_test.sh然后检查结果：
cat /opt/scripts/output.txt # 应该看到类似：helloStartup 2024-06-15 14:23:01 sudo tail -n 5 /var/log/auto_run_test.log # 应该看到完整的执行日志，包含“Script finished successfully”只有这一步成功了，才能继续下一步。如果报错，请根据日志内容逐行检查路径、权限、语法。
3. 主力方案：用systemd创建开机启动服务（推荐）
这是Ubuntu 16.04之后的官方推荐方式，稳定、可管理、可追溯。我们将为你的脚本创建一个专属的systemd服务单元。
3.1 创建服务定义文件
systemd服务文件必须放在/etc/systemd/system/目录下，以.service结尾：
sudo nano /etc/systemd/system/auto-run-test.service输入以下内容（每行含义已注释）：
[Unit] Description=Auto-run test script at boot After=multi-user.target # 确保在网络、文件系统等基础服务启动后再运行 StartLimitIntervalSec=0 # 禁用启动失败次数限制，便于调试 [Service] Type=oneshot # 脚本执行完即退出，非长期运行服务 ExecStart=/opt/scripts/auto_run_test.sh # 指定要执行的脚本 RemainAfterExit=yes # 即使脚本退出，也认为服务处于“激活”状态（方便状态查询） User=root # 以root身份运行（因脚本涉及系统级操作） WorkingDirectory=/opt/scripts StandardOutput=journal # 输出日志到systemd journal StandardError=journal # 可选：添加环境变量（如果脚本需要） # Environment="PATH=/usr/local/bin:/usr/bin:/bin" [Install] WantedBy=multi-user.target # 表示此服务应随多用户目标（即正常启动）一起启用3.2 重载systemd配置并启用服务
每次修改服务文件后，都必须通知systemd重新加载：
# 重载配置，让systemd识别新服务 sudo systemctl daemon-reload # 启用服务：确保它在下次开机时自动启动 sudo systemctl enable auto-run-test.service # （可选）立即启动服务，无需重启，用于快速验证 sudo systemctl start auto-run-test.service3.3 验证服务状态与日志
现在来检查一切是否按预期工作：
# 查看服务当前状态 sudo systemctl status auto-run-test.service # 正常输出应包含： # ● auto-run-test.service - Auto-run test script at boot # Loaded: loaded (/etc/systemd/system/auto-run-test.service; enabled; vendor preset: enabled) # Active: active (exited) since Sat 2024-06-15 14:30:22 CST; 1min 23s ago # 如果显示 "failed" 或 "inactive"，说明有问题，看下一步日志 # 查看详细执行日志（这是排查问题的黄金工具） sudo journalctl -u auto-run-test.service -n 20 --no-pager # 查看脚本自身日志 sudo tail -n 10 /var/log/auto_run_test.log如果status显示active (exited)，且日志里有Script finished successfully，恭喜，主力方案已成功！
4. 备选方案：启用并配置rc.local（仅当systemd不适用时）
某些老旧硬件或特殊容器环境可能不支持systemd，此时可启用传统的rc.local。但请注意：Ubuntu 22.04+默认不安装rc-local服务，必须手动启用。
4.1 创建并启用rc-local服务
# 创建rc.local文件（如果不存在） sudo nano /etc/rc.local输入以下内容（注意：第一行必须是#!/bin/bash，最后一行必须是exit 0）：
#!/bin/bash # 这里是你想执行的命令 cd /opt/scripts ./auto_run_test.sh exit 0保存后，设置执行权限：
sudo chmod +x /etc/rc.local接着，启用rc-localsystemd服务（这才是关键！）：
# 创建软链接，让systemd能识别rc.local sudo systemctl enable rc-local # 启动它（立即生效） sudo systemctl start rc-local # 检查状态 sudo systemctl status rc-local如果
status显示active (exited)，说明rc.local已成功启用。此时你再把脚本加进去，它才会在开机时运行。
4.2 关于/etc/profile的说明（不推荐用于开机启动）
原文提到“可追加到/etc/profile”，但这存在根本性误解：/etc/profile只在用户登录Shell时执行，比如你打开终端、或登录图形界面。它不会在系统启动早期（如网络未就绪、磁盘未挂载时）运行，更无法保证在systemd服务之前执行。
因此，除非你的需求明确是“每次我打开终端就运行一次”，否则请勿使用此方式配置“开机启动”。它不符合技术定义，也容易造成预期外的行为。
5. 开机验证与故障排查指南
配置完成后，最终检验是重启。但别急着sudo reboot——先做好三件事：
备份当前配置（以防万一）：
sudo cp /etc/systemd/system/auto-run-test.service ~/auto-run-test.service.bak确认服务已启用：
systemctl is-enabled auto-run-test.service # 应返回 "enabled"记录当前时间，方便日志定位：
date
5.1 重启并验证
sudo reboot系统重启后，登录进去，立即执行：
# 检查服务是否已自动运行 sudo systemctl status auto-run-test.service # 查看最新日志 sudo journalctl -u auto-run-test.service --since "1 hour ago" | grep -E "(started|finished|error)" # 检查脚本输出 cat /opt/scripts/output.txt sudo tail -n 5 /var/log/auto_run_test.log5.2 常见问题速查表
| 现象 | 最可能原因 | 解决方法 |
|---|---|---|
systemctl status显示inactive (dead)或failed | 脚本路径错误、权限不足、脚本内命令执行失败 | 用sudo journalctl -u xxx -n 50查看完整错误；检查/opt/scripts/auto_run_test.sh路径和权限；手动运行脚本测试 |
服务显示active (exited)但output.txt为空 | 脚本中cd失败，导致写入路径错误 | 在脚本开头加pwd >> /var/log/auto_run_test.log，确认当前工作目录 |
重启后服务没运行，is-enabled返回disabled | enable命令未成功执行，或daemon-reload遗漏 | 重新执行sudo systemctl daemon-reload && sudo systemctl enable auto-run-test.service |
rc-local服务启动失败，提示Unit rc-local.service not found | rc-local服务未安装（Ubuntu 22.04+） | 执行sudo systemctl enable rc-local会自动创建所需单元，若仍失败，检查/lib/systemd/system/rc-local.service是否存在 |
6. 总结：你已经掌握的不仅是脚本，更是系统思维
回顾整个过程，你其实已经完成了三件关键事：
- 学会了脚本编写规范：用绝对路径、加错误处理、写日志，告别“能跑就行”的粗糙思维；
- 掌握了现代Linux服务管理核心：理解了
systemd如何组织、启动、监控服务，这是运维和开发的通用语言； - 建立了可靠的验证闭环：从手动测试 → 服务启用 → 日志追踪 → 重启验证，每一步都有据可查，不再靠“猜”。
这不是一个孤立的技巧，而是你深入Ubuntu系统的一把钥匙。未来无论是部署Web服务、定时备份、还是运行AI推理脚本，这套方法论都完全适用。
最后提醒一句：所有修改都应在测试环境充分验证后再上生产机。安全永远是第一位的。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
