快速上手Ubuntu 16.04开机自启功能，实操分享
你是不是也遇到过这样的问题：写好了一个自动化脚本，每次重启电脑后还得手动运行？或者部署了一个服务，总得登录系统后再敲命令启动？在Ubuntu 16.04环境下，其实完全可以让系统在开机时自动执行你的任务——不用图形界面、不依赖用户登录、真正意义上的“开机即用”。
这篇文章不是照搬手册的理论堆砌，而是基于一个真实可用的镜像“测试开机启动脚本”整理出的完整实操路径。我会带你从零开始，一步步创建脚本、设置权限、修改系统配置，最后验证效果。所有操作都在标准Ubuntu 16.04桌面版环境下验证通过，不需要额外安装软件，不依赖systemd高级配置，也不需要理解复杂的init机制——你只需要会复制粘贴、会敲几条基础命令，就能搞定。
整篇内容聚焦一个目标：让你在30分钟内，让自己的脚本稳稳当当地在系统启动完成后自动跑起来。过程中我会指出哪些步骤容易出错、哪些写法看似合理实则无效、哪些细节决定成败。没有术语轰炸，只有可落地的操作和看得见的结果。
1. 创建可执行的启动脚本
脚本是整个流程的起点，也是最容易被忽略的一环。很多人以为随便写个.sh文件就能用，结果发现开机后什么都没发生。关键在于两点：路径要明确、内容要健壮。
我们推荐把脚本放在一个固定且易管理的位置，比如/home/用户名/Documents/scripts/。假设你的用户名是user（请替换成你实际的用户名），先创建目录和脚本文件：
mkdir -p /home/user/Documents/scripts nano /home/user/Documents/scripts/auto_run_test.sh在编辑器中输入以下内容（注意：不要直接复制网页上的引号，全部使用英文半角符号）：
#!/bin/bash # 记录启动时间，便于后续验证 echo "Startup at $(date)" > /home/user/Documents/scripts/output.txt # 进入指定工作目录（示例路径，请按需修改） cd /home/user/mywbc_v5_usb/build 2>/dev/null || echo "Warning: build directory not found" >> /home/user/Documents/scripts/output.txt # 执行你的主程序（此处为示例，替换为你的真实命令） if [ -x "./sim/sim" ]; then ./sim/sim > /home/user/Documents/scripts/sim_output.log 2>&1 & echo "Sim process started with PID $!" >> /home/user/Documents/scripts/output.txt else echo "Error: sim executable not found" >> /home/user/Documents/scripts/output.txt fi # 再次记录完成状态 echo "Startup completed" >> /home/user/Documents/scripts/output.txt这段脚本比参考博文中的版本更实用，原因有三：
- 使用绝对路径写入日志，避免因当前工作目录不确定导致文件写入失败；
- 加入了
2>/dev/null和||逻辑判断，防止目录不存在时脚本中断； - 对可执行文件做了存在性检查，并后台运行（
&），避免阻塞启动流程； - 每一步都追加日志，方便后续排查问题。
保存并退出（nano中按Ctrl+O→Enter→Ctrl+X）。
2. 设置脚本执行权限
Linux不会随意执行任何文本文件，必须显式赋予执行权限。这一步看似简单，但权限设错会导致脚本静默失败——既不报错，也不运行。
执行以下命令：
chmod +x /home/user/Documents/scripts/auto_run_test.sh这里推荐用+x而不是777。777虽然粗暴有效，但存在安全风险：它让所有用户都能读、写、执行该脚本。而+x只添加执行权限，保留原有读写权限，更符合最小权限原则。
验证是否设置成功：
ls -l /home/user/Documents/scripts/auto_run_test.sh你应该看到输出中包含-rwxr--r--或类似字段，其中的x表示执行权限已生效。
3. 启用并配置rc.local机制
Ubuntu 16.04默认使用System V init兼容模式，rc.local是官方支持的、最轻量级的开机自启入口。但它默认处于禁用状态，需要手动激活。
首先确认rc.local文件是否存在：
ls -l /etc/rc.local如果提示“No such file”，说明系统未生成该文件。此时需手动创建：
sudo nano /etc/rc.local输入以下标准模板内容（注意：这是完整文件内容，不要遗漏任何一行）：
#!/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 just change the execution # bits. # # By default this script does nothing. # Start custom script cd /home/user/Documents/scripts ./auto_run_test.sh exit 0关键点说明：
- 第一行
#!/bin/sh -e必须严格匹配，-e参数确保脚本遇到错误时立即退出，避免后续命令误执行； cd命令必须写在调用脚本之前，否则脚本内部的相对路径会失效；- 直接用
./auto_run_test.sh调用，不要加sudo——rc.local本身以root权限运行，加sudo反而可能因环境变量缺失导致失败； exit 0是强制要求，缺了会导致系统启动卡在最后阶段。
保存后，还要给rc.local赋予执行权限：
sudo chmod +x /etc/rc.local重要提醒：有些教程建议先改权限再编辑，这是误区。正确的顺序是——先创建/编辑内容，再统一赋权。因为
chmod 777等宽泛权限在生产环境中应避免，而+x足够且安全。
4. 验证rc.local服务状态
在Ubuntu 16.04中，rc.local由systemd托管为一个服务单元。即使你正确配置了文件，如果对应服务未启用，脚本依然不会运行。
检查服务状态：
sudo systemctl status rc-local如果显示inactive (dead)或not-found，说明服务未启用。启用它：
sudo systemctl enable rc-local sudo systemctl start rc-local启用后再次检查状态，应显示active (exited)。这表示rc.local机制已就绪，下次启动时将自动触发。
5. 手动模拟启动流程并调试
别急着重启！先在当前会话中模拟一次rc.local的执行过程，快速验证脚本是否能正常工作：
sudo /etc/rc.local执行后，检查日志文件：
cat /home/user/Documents/scripts/output.txt你应该看到类似这样的内容：
Startup at Mon Jun 10 14:22:35 CST 2024 Sim process started with PID 12345 Startup completed如果出现错误提示（如“build directory not found”），说明路径配置有误，返回第1步修正；如果文件为空，检查脚本权限和rc.local内容是否拼写错误。
这个手动验证步骤能帮你节省大量重启时间，是高效排错的关键习惯。
6. 重启验证与常见问题处理
确认手动执行无误后，执行最终验证：
sudo reboot系统重启后，等待约1分钟（给后台进程留出执行时间），然后打开终端，查看日志：
cat /home/user/Documents/scripts/output.txt如果看到完整的启动日志，说明配置成功。你还可以检查你的主程序是否正在运行：
ps aux | grep sim若看到sim进程，恭喜你，开机自启已稳定运行。
常见问题及解决方案
问题1：重启后output.txt文件不存在或为空
原因：脚本路径错误，或rc.local中cd命令指向的目录不存在。
解决：在rc.local中添加调试语句：
echo "Current dir: $(pwd)" >> /home/user/Documents/scripts/debug.log ls -l /home/user/Documents/scripts/ >> /home/user/Documents/scripts/debug.log问题2：脚本执行了，但主程序没启动
原因：主程序依赖图形界面、环境变量或特定用户权限。
解决：在脚本开头显式加载环境：
source /home/user/.profile export DISPLAY=:0问题3：系统启动变慢或卡在紫色屏幕
原因：rc.local中脚本未及时退出，或缺少exit 0。
解决：检查/etc/rc.local末尾是否有exit 0，并将耗时操作改为后台运行（加&）。
问题4：某些Ubuntu 16.04精简版没有rc.local
替代方案：编辑/etc/profile（仅适用于用户登录后启动，非纯开机启动）：
echo 'cd /home/user/Documents/scripts && ./auto_run_test.sh' | sudo tee -a /etc/profile但请注意，此方式依赖图形会话登录，无法实现真正的无人值守启动。
7. 进阶建议：让自启更可靠、更可控
完成基础配置只是第一步。在实际工程中，你可能还需要这些能力：
添加启动超时保护
防止脚本异常卡死影响系统启动，在rc.local中调用脚本时加上超时：
timeout 30s ./auto_run_test.sh实现服务化管理（可选）
如果你的脚本需要频繁启停或查看状态，可以将其注册为systemd服务：
sudo nano /etc/systemd/system/auto-run-test.service内容如下：
[Unit] Description=Auto Run Test Script After=multi-user.target [Service] Type=oneshot ExecStart=/home/user/Documents/scripts/auto_run_test.sh RemainAfterExit=yes [Install] WantedBy=multi-user.target启用服务：
sudo systemctl daemon-reload sudo systemctl enable auto-run-test.service日志集中管理
将脚本输出重定向到系统日志，便于统一查看：
logger -t "auto-run-test" "Starting sim process" ./sim/sim 2>&1 | logger -t "auto-run-test"这些进阶技巧不是必需的，但当你从“能用”迈向“好用”“稳定用”时，它们会成为关键支撑。
8. 总结：一条清晰、可复用的开机自启路径
回顾整个流程，我们构建了一条从脚本创建到稳定运行的完整链路：
- 脚本设计强调路径绝对化、错误可感知、日志可追溯，拒绝“黑盒式”执行；
- 权限设置坚持最小必要原则，用
+x代替777，兼顾安全与可用； rc.local配置遵循官方规范，确保兼容性和可维护性；- 验证环节采用手动模拟先行策略，大幅降低调试成本；
- 问题处理提供具体现象→根本原因→可操作解法的闭环思路。
Ubuntu 16.04虽已进入维护周期，但在嵌入式开发、教学实验、老旧设备升级等场景中仍有广泛使用。掌握这套开机自启方法，不仅能解决当前需求，更能为你理解Linux启动流程打下实践基础。
现在，你的脚本已经准备好迎接每一次开机。下一步，你可以把它扩展成监控服务、数据采集代理，或是自动化测试平台——起点虽小，但每一步都踏在真实的工程节奏上。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
