Linux系统开机自启全流程详解，图文并茂
在日常运维、嵌入式开发或AI服务部署中，经常需要让某些程序、服务或脚本在系统启动后自动运行——比如拉起模型推理服务、初始化硬件设备、挂载网络存储，或者像本镜像所演示的：执行一条简单的测试脚本。但很多初学者一碰到“开机自启”，就卡在“该改哪个文件”“为什么改了没生效”“Ubuntu新版怎么没了rc.local”这类问题上。本文不讲抽象概念，不堆术语，全程基于真实操作，用Ubuntu 16.04和Tina系统双环境验证，手把手带你走通从编写脚本、配置权限、修改启动项到验证效果的完整闭环流程。每一步都附关键命令、典型输出和避坑提示，真正实现“照着做，就能成”。
1. 明确目标与适用场景
在开始操作前，先厘清两个关键问题：我们要启动什么？在哪种系统上启动？
1.1 本教程解决的核心问题
- 让一个自定义Shell脚本（如
/opt/test-startup.sh）在系统启动完成、登录界面出现前就自动执行 - 兼容传统SysV init风格（如Ubuntu 16.04默认）和轻量级嵌入式init（如Allwinner Tina SDK）
- 不依赖systemd高级特性，避免因版本差异导致配置失效
- ❌ 不涉及GUI桌面环境下的用户级自启（如
.bashrc或GNOME Startup Applications） - ❌ 不讲解容器化或云平台的启动管理（如Docker Entrypoint、K8s InitContainer）
1.2 为什么选择/etc/rc.local方案？
虽然现代Linux普遍采用systemd，但/etc/rc.local因其极简、稳定、跨发行版兼容性强，仍是嵌入式、边缘设备和快速验证场景的首选。它本质是一个被系统init进程最后调用的“兜底脚本”，只要文件存在且可执行，其中的命令就会按顺序执行——就像给系统加了一条“开机必做清单”。
小知识补充：Linux系统在开机完成后自动运行
/etc/rc.local这个文件，因此我们只要将代码写进这个文件就可以实现开机自动运行啦，很省事！
但请注意：这个“很省事”有个前提——你得确保它真的被调用了。Ubuntu 18.04+默认禁用rc.local服务，而Tina系统需手动启用init脚本支持。本文会逐一击破这些隐藏关卡。
2. 准备工作：创建并验证测试脚本
一切自启逻辑都始于一个能独立运行的脚本。我们先创建一个清晰可验证的测试脚本，为后续调试打下基础。
2.1 编写测试脚本
新建脚本文件，路径建议统一放在/opt/下（非系统关键目录，权限友好）：
sudo nano /opt/test-startup.sh输入以下内容（功能：记录当前时间戳到日志，并点亮一个LED或打印提示）：
#!/bin/bash # 测试开机启动脚本 # 功能：开机时自动运功脚本中的命令 # 记录启动时间到日志文件 echo "[$(date '+%Y-%m-%d %H:%M:%S')] test-startup.sh executed successfully" >> /var/log/test-startup.log # 模拟实际任务：例如ifconfig wlan0 up（仅示例，按需替换） # ifconfig wlan0 up 2>/dev/null || true # 打印到控制台（便于调试，生产环境可注释） echo " test-startup.sh has run at boot time"2.2 设置脚本权限并手动测试
脚本必须有可执行权限，否则rc.local调用时会静默失败：
sudo chmod +x /opt/test-startup.sh立即手动执行一次，确认脚本本身无语法错误、路径正确、日志可写：
sudo /opt/test-startup.sh检查日志是否生成：
sudo tail -n 1 /var/log/test-startup.log # 应输出类似：[2024-05-20 14:30:22] test-startup.sh executed successfully成功标志：日志文件存在且内容正确。若报错
Permission denied，检查/var/log/目录权限；若报错No such file or directory，确认路径拼写。
3. 核心配置：修改/etc/rc.local并启用服务
这是全流程最关键的一步。不同系统对rc.local的支持方式不同，我们将分别处理Ubuntu 16.04（SysV init）和Tina（BusyBox init）两种典型环境。
3.1 Ubuntu 16.04：标准SysV init配置
Ubuntu 16.04默认使用SysV init，rc.local开箱即用，但需确保其服务已启用。
步骤1：编辑rc.local文件
sudo nano /etc/rc.local在exit 0之前（必须在其上方），添加你的脚本调用行：
# your command1 /opt/test-startup.sh # your command2 # ifconfig wlan0 up # ifconfig wlan0 yttc 123456789 exit 0重要提醒：
exit 0不能少，也不能放在脚本调用之后！它是rc.local脚本的结束标记，缺失会导致后续系统服务无法启动。
步骤2：确保rc.local服务已启用
虽然文件存在，但服务可能未激活。执行：
sudo systemctl enable rc-local.service sudo systemctl start rc-local.service验证服务状态：
sudo systemctl status rc-local.service # 应显示 "active (exited)" 且无报错3.2 Tina系统（Allwinner SDK）：BusyBox init适配
Tina基于OpenWrt，使用精简的BusyBox init，rc.local需手动创建并确保init进程读取。
步骤1：创建rc.local文件（若不存在）
sudo nano /etc/rc.local内容格式与Ubuntu一致，但必须以#!/bin/sh开头（BusyBox sh解析器要求）：
#!/bin/sh # Tina系统rc.local启动脚本 # 调用测试脚本 /opt/test-startup.sh exit 0步骤2：赋予可执行权限
sudo chmod +x /etc/rc.local步骤3：确认init脚本加载逻辑
Tina的/etc/init.d/rcS是启动入口，需确保它包含对rc.local的调用。检查：
sudo cat /etc/init.d/rcS | grep rc.local正常应有类似行：
[ -f /etc/rc.local ] && /etc/rc.local若无此行，需手动添加（在rcS末尾exit 0前插入）：
# Run local startup script [ -f /etc/rc.local ] && /etc/rc.local验证：重启后查看
/var/log/test-startup.log是否有新记录，即可确认rc.local被成功调用。
4. 常见问题排查与解决方案
即使严格按步骤操作，仍可能遇到“脚本没执行”“日志为空”“系统卡在启动界面”等问题。以下是高频故障点及对应解法。
4.1 故障现象：日志文件无新增记录，脚本未执行
| 可能原因 | 快速诊断命令 | 解决方案 |
|---|---|---|
rc.local文件权限不足 | ls -l /etc/rc.local | sudo chmod 755 /etc/rc.local |
| 脚本路径错误或不存在 | sudo /etc/rc.local（手动执行rc.local） | 检查/opt/test-startup.sh路径，用绝对路径 |
rc.local中缺少exit 0 | sudo tail -n 5 /etc/rc.local | 补全exit 0，确保在最后一行 |
| 系统未启用rc-local服务（Ubuntu 16.04） | sudo systemctl is-enabled rc-local.service | sudo systemctl enable rc-local.service |
4.2 故障现象：系统启动变慢或卡在logo界面
这通常意味着rc.local中某条命令阻塞了启动流程（如等待网络、挂载超时）。解决方案：
所有耗时命令添加超时与后台化：
# 错误：可能无限等待 ping -c 4 google.com # 正确：10秒超时，后台运行不阻塞 timeout 10s ping -c 4 google.com >/dev/null 2>&1 &关键服务启动后才执行：在脚本中加入等待逻辑，例如：
# 等待网络就绪（最多等待60秒） for i in $(seq 1 60); do if ip link show eth0 | grep "state UP" > /dev/null; then break fi sleep 1 done /opt/test-startup.sh
4.3 故障现象：脚本执行了，但部分命令无效（如ifconfig不生效）
原因：rc.local在系统网络服务启动之前运行，此时网卡可能未初始化。解决方案：
方法1（推荐）：将网络相关命令移至网络服务启动后。Ubuntu下可创建systemd服务依赖：
sudo nano /etc/systemd/system/test-startup.service内容：
[Unit] Description=Test Startup Script After=network.target [Service] Type=oneshot ExecStart=/opt/test-startup.sh RemainAfterExit=yes [Install] WantedBy=multi-user.target启用：
sudo systemctl daemon-reload && sudo systemctl enable test-startup.service方法2（兼容性好）：在
rc.local中延迟执行：(sleep 10 && /opt/test-startup.sh) &
5. 进阶技巧：让自启更健壮、更可控
生产环境中，仅“能跑”不够，还需“可管”“可查”“可回滚”。以下技巧大幅提升可靠性。
5.1 日志分级与错误捕获
增强脚本健壮性，捕获错误并分类记录：
#!/bin/bash LOG_FILE="/var/log/test-startup.log" exec >> "$LOG_FILE" 2>&1 echo "=== $(date) ===" # 使用set -e让任一命令失败即退出 set -e # 记录执行环境 echo "Running as: $(whoami)" echo "System: $(uname -a)" # 执行主任务，捕获错误 if /opt/test-startup.sh; then echo " Main task succeeded" else echo "❌ Main task failed with exit code $?" exit 1 fi5.2 条件化启动：仅在特定硬件或模式下运行
例如，只在开发板启动时运行，PC上跳过：
# 在test-startup.sh中添加 if [ -f /proc/device-tree/model ]; then # Allwinner平台特有，读取设备型号 MODEL=$(cat /proc/device-tree/model 2>/dev/null) if echo "$MODEL" | grep -q "Tina"; then echo "Running on Tina platform..." # 执行硬件初始化命令 fi else echo "Not an embedded platform, skipping hardware init" fi5.3 安全加固：避免脚本被意外覆盖或篡改
对关键启动文件设置不可修改位（immutable）：
# 设置rc.local为不可修改（需root权限） sudo chattr +i /etc/rc.local # 恢复修改：sudo chattr -i /etc/rc.local # 设置测试脚本为只读 sudo chmod 555 /opt/test-startup.sh注意：
chattr +i后，连root也无法编辑文件，务必确认配置无误再执行。
6. 总结：从原理到落地的关键要点
回顾整个流程，Linux开机自启并非玄学，而是由“脚本准备→权限配置→启动项注册→系统验证”四个环环相扣的环节组成。本文通过Ubuntu 16.04和Tina双环境实操，帮你穿透表层命令，抓住本质：
- 核心原理：
/etc/rc.local是init进程的“收尾任务单”，它的存在和可执行性决定了自启能否触发； - 成败关键：
exit 0的位置、脚本的绝对路径、rc.local的可执行权限，三者缺一不可； - 环境差异：Ubuntu 16.04重在
systemctl enable，Tina重在/etc/init.d/rcS的调用链完整性； - 调试铁律：永远先手动执行脚本和
rc.local，再依赖重启验证；日志是唯一可信证据； - 生产思维：添加超时、错误捕获、条件判断、安全锁，让自启从“能用”升级为“可靠”。
现在，你可以自信地将任何Shell任务植入系统启动流程——无论是部署AI模型服务、初始化摄像头，还是让开发板一上电就进入工作状态。真正的自动化，始于对启动机制的透彻理解。
--- > **获取更多AI镜像** > > 想探索更多AI镜像和应用场景？访问 [CSDN星图镜像广场](https://ai.csdn.net/?utm_source=mirror_blog_end)，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
