用测试镜像做了个开机自启项目，附完整过程

用测试镜像做了个开机自启项目，附完整过程

1. 引言：为什么需要开机自启脚本？

在嵌入式系统或路由器等长期运行的设备中，自动化启动任务是保障服务稳定性的关键环节。通过配置开机自启脚本，可以在系统重启后自动恢复网络服务、日志采集、监控程序等核心功能，避免人工干预。

本文基于一个名为“测试开机启动脚本”的镜像环境，完整记录了实现开机自启功能的技术路径。我们将从两种主流方法入手——使用/etc/rc.local和创建/etc/init.d初始化脚本，详细说明每一步操作、注意事项及验证方式，确保方案可落地、易复用。

2. 方法一：利用/etc/rc.local实现简单自启

2.1 原理与适用场景

/etc/rc.local是 Linux 系统传统启动流程中的最后一个用户级脚本，在多用户模式初始化完成后执行。它适用于轻量级、一次性启动命令的场景，如挂载文件系统、启动守护进程、写入调试信息等。

该方法优点在于：

• 配置简单，无需编写完整服务脚本
• 兼容性强，几乎所有 OpenWrt 版本都支持
• 调试方便，易于排查错误

但其局限性也明显：

• 不支持复杂的依赖管理
• 无法通过标准命令（如service start myscript）控制
• 启动顺序不可控（总是在最后阶段）

2.2 操作步骤详解

编辑 rc.local 文件

首先，使用文本编辑器打开/etc/rc.local文件：

vi /etc/rc.local

或者如果你更习惯nano：

nano /etc/rc.local

添加自定义命令

在exit 0之前插入你要执行的命令。例如，我们希望在每次开机时生成一个带有时间戳的测试文件：

# 写入当前时间到临时文件 echo "System boot at $(date)" >> /tmp/boot.log

完整示例内容如下：

#!/bin/sh # Put your custom commands here that should be executed once # the system has booted. echo "System boot at $(date)" >> /tmp/boot.log exit 0

注意：务必确保所有命令位于exit 0之前，否则不会被执行。

保存并退出编辑器

• 使用vi：按下ESC键，输入:wq并回车。
• 使用nano：按Ctrl+O保存，Ctrl+X退出。

设置执行权限

确认/etc/rc.local具备可执行权限：

chmod +x /etc/rc.local

你可以通过以下命令检查权限是否正确：

ls -l /etc/rc.local

输出应包含-rwxr-xr-x权限标识。

2.3 验证脚本是否生效

重启系统以验证效果：

reboot

系统重新登录后，查看/tmp/boot.log是否已生成且包含最新时间戳：

cat /tmp/boot.log

预期输出类似：

System boot at Mon Apr 5 10:23:45 UTC 2025 System boot at Mon Apr 5 10:25:12 UTC 2025

若能看到多条记录，则说明脚本成功在每次开机时执行。

3. 方法二：创建/etc/init.d自定义服务脚本

3.1 核心优势与工作原理

相比rc.local，将脚本注册为/etc/init.d服务是一种更规范、更灵活的方式。OpenWrt 的procd初始化系统允许你：

• 定义启动优先级（START 数值）
• 支持start、stop、restart、enable等标准操作
• 更好地集成系统日志和服务状态管理
• 实现服务依赖和守护进程管理（进阶用法）

这种方法更适合部署生产级应用或需要精细控制的服务。

3.2 创建并配置 init.d 脚本

创建脚本文件

新建一个名为myscript的脚本文件：

vi /etc/init.d/myscript

编写脚本内容

输入以下内容：

#!/bin/sh /etc/rc.common # START=99 表示启动顺序，数字越大越晚启动 START=99 # start 函数：系统启动时调用 start() { echo "Custom script started at $(date)" >> /tmp/initd_boot.log # 可在此添加更多命令，如启动 Python 脚本、开启监听端口等 } # stop 函数（可选）：关机或手动停止时调用 stop() { echo "Custom script stopped at $(date)" >> /tmp/initd_boot.log }

说明：

• /etc/rc.common提供了对start、stop等命令的封装
• START=99确保脚本在大多数系统服务之后运行
• start()和stop()是标准生命周期函数

保存并设置权限

保存文件后，赋予可执行权限：

chmod +x /etc/init.d/myscript

3.3 注册并启用服务

使用 OpenWrt 的服务管理工具启用脚本：

/etc/init.d/myscript enable

此命令会在/etc/rc.d/目录下创建软链接，如S99myscript，表示系统将在第 99 顺位执行该脚本。

提示：enable仅需执行一次。后续重启将自动加载。

3.4 手动测试脚本运行

在不重启的情况下测试脚本是否正常工作：

/etc/init.d/myscript start

检查日志输出：

cat /tmp/initd_boot.log

预期输出：

Custom script started at Mon Apr 5 10:30:11 UTC 2025

你也可以尝试停止服务：

/etc/init.d/myscript stop

再次查看日志，确认stop函数也被触发。

3.5 查看服务状态与管理命令

OpenWrt 支持以下标准命令管理init.d脚本：

这些命令大大提升了运维效率，尤其适合远程设备维护。

4. 对比分析：rc.local vs init.d

为了帮助读者做出合理选择，以下是两种方法的全面对比：

结论建议：

• 初学者或临时测试：优先使用rc.local
• 正式项目或需长期维护的服务：必须采用init.d方案

5. 实践中的常见问题与解决方案

5.1 脚本未执行？检查点清单

当发现脚本没有按预期运行时，请依次排查以下问题：

1. 权限不足

   chmod +x /etc/rc.local # 对 rc.local chmod +x /etc/init.d/myscript # 对 init.d 脚本

2. 缺少 enable 操作

   /etc/init.d/myscript enable # 必须执行才能开机启动

3. 语法错误导致中断

   • 使用sh -n script.sh检查语法
   • 在脚本开头添加set -x输出执行轨迹

4. 路径问题

   • 避免使用相对路径
   • 推荐使用绝对路径调用外部程序，如/usr/bin/python3 /root/myapp.py

5. 环境变量缺失

   • 若脚本依赖特定环境变量（如 PATH），应在脚本中显式声明：

     export PATH="/usr/sbin:/usr/bin:/sbin:/bin"

5.2 日志位置建议

为便于后期排查，建议将日志输出到固定位置：

• 临时日志：/tmp/boot.log（重启会清空）
• 持久日志：/var/log/boot.log（需确保目录存在）

创建持久化日志目录：

mkdir -p /var/log touch /var/log/boot.log

并在脚本中统一写入：

echo "$(date): Service started" >> /var/log/boot.log

6. 总结

本文围绕“测试开机启动脚本”这一镜像环境，系统性地实现了两种开机自启方案，并提供了完整的操作流程、代码示例与排错指南。

• 方法一（rc.local）：适合快速验证和简单任务，5分钟内即可完成配置；
• 方法二（init.d）：符合工程规范，支持服务化管理，是生产环境的首选方案；
• 综合建议：开发阶段可用rc.local快速迭代，最终部署应迁移到init.d框架。

无论你是嵌入式开发者、家庭网关爱好者，还是 IoT 设备维护人员，掌握这两种技术都将显著提升系统的自动化水平和稳定性。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。