嵌入式开发必备：开机自动运行初始化脚本

在嵌入式设备量产部署或现场调试中，你是否遇到过这样的问题：每次上电后都要手动执行一连串命令——配置网络、挂载存储、启动服务、校准传感器？重复操作不仅效率低，还容易出错。更关键的是，很多嵌入式设备根本没有交互界面，根本没法“手动”操作。

其实，Linux系统早已为我们准备好了成熟可靠的机制：让关键初始化任务在系统启动完成的最后阶段自动执行。这不是什么黑科技，而是嵌入式工程师日常开发中必须掌握的基础能力。本文不讲抽象理论，只聚焦一件事——如何让你写的脚本，在设备通电开机后，稳稳当当地跑起来。

我们以实际可验证的镜像“测试开机启动脚本”为载体，用Ubuntu 16.04和Tina系统为典型环境，手把手带你完成从编写、测试到稳定运行的全过程。所有步骤都经过真实设备验证，没有“理论上可行”，只有“现在就能用”。

1. 为什么是rc.local？它到底靠不靠谱

1.1 它不是“备选方案”，而是“标准路径”

很多新手会疑惑：systemd有service，init.d有脚本，还有crontab的@reboot，为什么偏偏推荐/etc/rc.local？答案很简单：它最轻量、最通用、最贴近嵌入式场景需求。

它在系统初始化流程的末尾执行，此时内核、驱动、基础服务（如networking）均已就绪，你的脚本可以放心调用ifconfig、mount、modprobe等命令；
它不依赖复杂的unit文件语法，就是一个普通的shell脚本，写法直观，排查简单；
在Ubuntu 16.04（使用SysV init）、Tina（基于OpenWrt，同样兼容rc.local）等广泛使用的嵌入式发行版中，它默认启用且行为一致；
它天然支持顺序执行、错误检查和退出码控制，比拼凑多个service更可控。

重要提醒：不要把它当成“临时方案”。在资源受限、追求稳定性的嵌入式产品中，一个精简可靠的rc.local，远比一堆相互依赖的systemd service更值得信赖。

1.2 它的工作原理：系统启动流程中的“最后一公里”

Linux启动过程大致分为：BIOS/UEFI → Bootloader（如U-Boot）→ Kernel → Init进程 → 运行级别（runlevel）脚本。rc.local正是Init进程在进入默认运行级别（通常是multi-user.target）前，执行的最后一个用户级脚本。

你可以把它理解成系统对你说的那句：“所有底层都准备好了，现在轮到你来干点具体的事了。”

这个时机非常关键——太早，网卡驱动可能还没加载；太晚，某些服务可能已因依赖缺失而启动失败。rc.local恰好卡在这个黄金节点，既安全又高效。

2. 动手写一个真正能用的初始化脚本

2.1 脚本结构：三要素缺一不可

一个能稳定工作的rc.local，必须包含且仅包含以下三个部分：

Shebang行：声明解释器，#!/bin/sh是嵌入式环境最安全的选择；
你的业务命令：按需执行的初始化操作，每条命令独占一行；
exit 0：这是硬性要求，告诉系统“我执行成功了”，缺了它，整个启动流程可能被阻塞或报错。

下面是一个经过实测的模板，你可以直接复制修改：

#!/bin/sh # /etc/rc.local # 等待网络就绪（防止wlan0未加载就执行） sleep 3 # 启用无线网卡 ifconfig wlan0 up # 配置无线网卡IP（示例地址） ifconfig wlan0 192.168.1.100 netmask 255.255.255.0 # 挂载外部SD卡（假设设备号为/dev/mmcblk1p1） mkdir -p /mnt/sdcard mount /dev/mmcblk1p1 /mnt/sdcard # 启动自定义数据采集服务（假设可执行文件在/opt/bin/下） /opt/bin/data_collector & # 必须！结尾退出码为0 exit 0

2.2 关键细节：为什么这些“小地方”决定成败

sleep 3不是可有可无：在嵌入式系统中，驱动加载、硬件就绪存在不确定性。加几秒等待，能避免90%的“命令找不到设备”的报错。
&后台运行很重要：如果你的程序是长期运行的服务（如采集、监控），务必加&，否则rc.local会卡在这里，导致后续系统服务无法启动。
路径必须写全：/opt/bin/data_collector不能简写为data_collector，因为rc.local的PATH环境变量非常精简，不包含自定义路径。
exit 0是铁律：无论你前面执行了多少命令，最后一行必须是exit 0。系统通过这个退出码判断脚本是否成功。如果脚本末尾没有它，或者某条命令失败后没处理，系统可能认为启动异常，进而影响日志、网络甚至GUI。

3. 从编写到生效：四步验证法

光写完脚本还不够，必须经过完整验证。我们采用“本地测试→权限检查→启动模拟→真机验证”四步法，确保万无一失。

3.1 第一步：在Shell里直接运行，看输出是否符合预期

不要急着重启！先用最简单的方式验证逻辑：

# 给脚本添加执行权限（首次需要） sudo chmod +x /etc/rc.local # 手动执行一次，观察输出 sudo /etc/rc.local

如果看到类似ifconfig: SIOCSIFFLAGS: No such device的错误，说明wlan0还没加载，这时你就该加sleep或改用udev规则；如果一切命令都静默成功，说明脚本逻辑本身没问题。

3.2 第二步：检查权限与路径，排除环境陷阱

嵌入式系统常有特殊限制，务必确认两点：

文件权限：/etc/rc.local必须对root可读可执行。用ls -l /etc/rc.local检查，正确输出应为-rwxr-xr-x 1 root root ...；
解释器存在：运行which sh，确认/bin/sh存在。某些极简镜像可能用busybox sh，但#!/bin/sh依然兼容。

3.3 第三步：模拟启动流程，提前发现阻塞点

很多问题只在启动时暴露。Ubuntu 16.04提供了一个安全的模拟方式：

# 使用systemd模拟（即使不用systemd，此命令也有效） sudo systemctl daemon-reload sudo systemctl restart rc-local

然后查看日志：

sudo journalctl -u rc-local -n 20 --no-pager

日志里会清晰显示每条命令的执行结果和耗时，是调试的黄金依据。

3.4 第四步：真机断电重启，见证最终效果

完成前三步后，进行终极验证：给设备断电，再上电。耐心等待约30秒（取决于系统复杂度），然后通过串口或SSH连接，检查：

ifconfig wlan0是否已配置好IP；
mount | grep sdcard是否成功挂载；
ps aux | grep data_collector是否在运行。

只要这三项都满足，恭喜你，初始化脚本已正式服役。

4. 常见问题与实战解决方案

4.1 “脚本执行了，但我的服务没起来”

最常见原因：服务启动太快，依赖的资源还没准备好。例如，你的程序要访问/dev/ttyS1，但串口驱动加载稍慢。

解决方法：在启动命令前加入健壮的等待循环：

# 等待串口设备出现，最多等10秒 for i in $(seq 1 10); do if [ -c "/dev/ttyS1" ]; then break fi sleep 1 done /opt/bin/my_app &

4.2 “重启后rc.local不执行，日志里也没记录”

这通常意味着rc-local服务被禁用。在Ubuntu 16.04中，运行：

sudo systemctl enable rc-local sudo systemctl start rc-local

Tina系统则需检查/etc/init.d/rc.local是否已注册为启动项，通常执行/etc/init.d/rc.local enable即可。

4.3 “想让脚本在特定条件下才运行，比如只在调试模式下”

rc.local完全支持条件判断。你可以读取一个标志文件，或检查某个GPIO状态：

# 如果存在 /tmp/debug_mode 文件，则执行调试命令 if [ -f /tmp/debug_mode ]; then echo "Debug mode active" /usr/bin/screen -dmS debug_log tail -f /var/log/messages fi

这样，你只需在调试时touch /tmp/debug_mode，生产环境则完全不受影响。

5. 进阶技巧：让初始化更智能、更可靠

5.1 日志记录：出了问题，第一时间知道哪里坏了

在脚本开头加入日志重定向，所有输出都会保存：

#!/bin/sh exec >> /var/log/rc_local.log 2>&1 echo "$(date): rc.local started" # ... your commands ... echo "$(date): rc.local finished" exit 0

这样，每次启动的问题都能在/var/log/rc_local.log里找到线索，无需盲猜。

5.2 错误处理：一条命令失败，不该让整个初始化瘫痪

用|| true忽略单条命令失败，或用set -e让任何失败立即退出（适合关键路径）：

# 方式1：容忍非关键错误 ifconfig eth0 up || true # 方式2：关键步骤必须成功，否则停止 set -e modprobe my_sensor_driver echo 1 > /sys/class/gpio/export

选择哪种，取决于你的业务逻辑对容错的要求。

5.3 多环境适配：一套脚本，适配Ubuntu和Tina

两个系统路径略有差异。用uname -a或检查文件存在性做适配：

# 自动识别系统类型 if grep -q "ubuntu" /etc/os-release; then LOG_PATH="/var/log" elif grep -q "tina" /etc/openwrt_release; then LOG_PATH="/tmp" else LOG_PATH="/tmp" fi echo "Using log path: $LOG_PATH"

这样，同一份rc.local就能在不同镜像中无缝工作。