news 2026/4/17 18:58:23

测试开机启动脚本全流程演示，一看就会

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
测试开机启动脚本全流程演示，一看就会

测试开机启动脚本全流程演示，一看就会

你是不是也遇到过这样的问题：写好了自动化脚本，却总在重启后发现它根本没运行？或者明明加了启动项，系统一重启就“失联”？别急，这不是你的脚本有问题，大概率是启动流程没走对——开机启动这件事，看似简单，实则藏着好几个关键环节：脚本位置、执行权限、依赖顺序、服务注册……漏掉任何一环，脚本都会安静地“躺平”。

这篇内容不讲抽象原理，不堆术语，只带你从零开始，完整走一遍真实环境下的开机启动脚本测试全流程。无论你用的是 OpenWrt、树莓派系统、还是基于 BusyBox 的嵌入式 Linux 环境，只要系统支持/etc/rc.local或/etc/init.d机制，这套方法都管用。全程只需 5 分钟，连命令怎么输、哪里容易出错、怎么快速验证，都给你标得清清楚楚。

我们不假设你懂 init 系统，也不要求你会写 shell 脚本——文末会附一个可直接复制粘贴的最小可用示例，你照着敲完就能看到/tmp/test_boot.log里多了一行时间戳。这才是真正“一看就会”的意思。

1. 明确目标：你要让什么在开机时跑起来？

在动手前，请先确认一件事：你真正想启动的，是一个单次执行的命令，还是一个需要持续运行的服务？这个判断直接决定你该走哪条路。

  • 如果只是想开机时自动执行一条命令（比如创建一个日志文件、设置某个网络参数、启动一个 Python 小程序），那/etc/rc.local是最轻量、最直观的选择。
  • 如果你需要更精细的控制——比如脚本要等网络就绪后再运行、支持start/stop/restart、能被系统服务管理器识别——那就得走/etc/init.d路线。

本文两种方式都覆盖，但建议新手先从/etc/rc.local入手。它就像系统的“便签纸”，写上去、设好权限，系统启动最后阶段就会帮你读一遍、执行一遍，逻辑清晰，出错好排查。

小提醒：有些新版 OpenWrt 或精简系统默认禁用了rc.local，不是你操作错了，而是它压根没启用。别慌，后面会教你怎么检查和激活它。

2. 方法一：用/etc/rc.local快速启动（推荐新手）

2.1 检查rc.local是否存在且可用

不是所有系统都默认启用这个文件。先登录设备，执行：

ls -l /etc/rc.local

如果返回类似：

-rwxr-xr-x 1 root root 487 Jan 1 00:00 /etc/rc.local

说明文件存在，且已有执行权限（看开头的rwx）。

如果提示No such file or directory，说明系统没自带，你需要手动创建：

touch /etc/rc.local chmod +x /etc/rc.local

接着用编辑器打开它：

vi /etc/rc.local

为什么推荐vi？
在资源受限的嵌入式环境里，vi几乎必装，而nano可能未预装。如果你习惯nano，确保它已安装：opkg install nano（OpenWrt）或apt install nano（Debian系）。

2.2 编写可验证的测试脚本

别一上来就写复杂逻辑。我们先放一个肉眼可见、秒级验证的命令：

#!/bin/sh # /etc/rc.local # 在 exit 0 前添加你的命令 echo "=== Boot test started at $(date) ===" >> /tmp/test_boot.log sleep 2 echo "Script executed successfully." >> /tmp/test_boot.log exit 0

关键细节：

  • #!/bin/sh是可选的，但加上更规范；
  • 所有命令必须写在exit 0之前，否则不会执行；
  • >>是追加写入，避免每次重启都覆盖日志；
  • sleep 2是故意加的，方便你后续用ps查看进程是否真在启动阶段运行。

保存退出（vi下按ESC→ 输入:wq→ 回车）。

2.3 验证权限与语法

即使文件存在，也可能因权限不足或语法错误导致静默失败。分两步检查：

① 确认可执行权限：

chmod +x /etc/rc.local

② 手动模拟执行一次（不重启！）：

/etc/rc.local

然后立刻查看日志：

cat /tmp/test_boot.log

你应该看到：

=== Boot test started at Thu Jan 1 00:00:00 UTC 1970 === Script executed successfully.

这一步成功，说明脚本本身没问题，接下来就只剩“等重启”了。

2.4 重启并验证是否真在开机时运行

执行：

reboot

等待设备完全重启后，再次登录，立即检查日志：

cat /tmp/test_boot.log

如果内容比上次多了一行（时间戳更新了），恭喜，你的脚本已成功融入开机流程。

常见卡点排查：

  • 日志没更新？先确认/tmp是内存文件系统（df -h查看），重启后不会清空；
  • 时间戳还是旧的？可能是rc.local没被执行，检查/etc/rc.d/S99rc.local是否存在（OpenWrt 中这是软链接，指向/etc/init.d/rc.local）；
  • 提示Permission denied？一定是chmod +x漏了，再执行一遍。

3. 方法二：用/etc/init.d创建可管理服务（适合进阶需求）

当你需要脚本具备启停控制、依赖声明、或与其他服务协同时，/etc/init.d是标准做法。它本质是把你的脚本注册成一个“系统服务”。

3.1 创建服务脚本文件

我们起个名字叫testboot：

vi /etc/init.d/testboot

填入以下内容（已适配 OpenWrt 和通用 BusyBox 环境）：

#!/bin/sh /etc/rc.common # 启动顺序：数字越小越早执行，99 是较晚时机，适合依赖网络的服务 START=99 # 描述信息（可选，但建议写） USE_PROCD=1 start_service() { # procd 方式启动（OpenWrt 推荐） procd_open_instance procd_set_param command /bin/sh -c 'echo "=== Service start at $(date) ===" >> /tmp/test_boot.log && sleep 3 && echo "Service running." >> /tmp/test_boot.log' procd_set_param respawn # 自动重启（可选） procd_close_instance } # 如果不用 procd（如老版本或非 OpenWrt），取消下面注释，注释掉上面 start_service # start() { # echo "=== Service start at $(date) ===" >> /tmp/test_boot.log # sleep 3 # echo "Service running." >> /tmp/test_boot.log # }

说明：

  • START=99表示它在大多数基础服务之后启动，适合需要网络、存储挂载完成的场景；
  • USE_PROCD=1是 OpenWrt 特有机制，让脚本能被procd进程管理，更稳定；
  • 如果你用的是非 OpenWrt 系统（如树莓派 Raspbian），直接用下方注释掉的start()函数即可。

保存退出。

3.2 赋予权限并注册服务

chmod +x /etc/init.d/testboot /etc/init.d/testboot enable

enable命令会在/etc/rc.d/下创建对应软链接（如S99testboot），告诉系统“这个服务要开机自启”。

3.3 手动测试服务是否正常

别急着重启，先本地验证：

/etc/init.d/testboot start

然后检查日志：

cat /tmp/test_boot.log

应看到新增的Service start at ...和Service running.。

再试试停止：

/etc/init.d/testboot stop

虽然我们的脚本没写stop()函数，但procd会自动终止其子进程，日志不会新增内容——这说明服务管理是生效的。

3.4 重启验证全流程

reboot

重启后检查：

/etc/init.d/testboot status # 查看状态（OpenWrt） ps | grep testboot # 查看进程是否存在 cat /tmp/test_boot.log # 确认日志有新记录

如果三者都符合预期，说明你的服务已真正融入系统启动生命周期。

4. 两种方法对比与选择建议

维度/etc/rc.local/etc/init.d
上手难度（改一行代码就行）☆（需理解服务结构）
适用场景单次命令、简单初始化需启停控制、依赖管理、长期运行
调试便利性直接执行/etc/rc.local即可验证需用/etc/init.d/xxx start测试
系统兼容性几乎所有 Linux 发行版支持OpenWrt 原生支持；其他系统需适配 init 脚本格式
错误反馈失败时通常无提示，靠日志排查status命令可查运行状态，更透明

给你的行动建议：

  • 第一次尝试？死磕/etc/rc.local，把它跑通，建立信心；
  • 脚本要长期运行（比如监听端口、轮询传感器）？果断切到/etc/init.d；
  • 不确定用哪个？先写rc.local版本，跑通后再迁移到init.d——逻辑几乎一样，只是包装方式不同。

5. 实用技巧与避坑指南

5.1 让脚本更健壮的 3 个关键点

  1. 路径要写全
    别写python myscript.py，而要写/usr/bin/python /root/myscript.py。开机时$PATH可能不完整，绝对路径最保险。

  2. 重定向所有输出
    即使是echo，也建议重定向到日志，避免因终端不可用导致卡住：

    /usr/bin/python /root/myscript.py >> /tmp/myscript.log 2>&1

  3. 加延时等关键服务就绪
    如果脚本依赖网络，加个简单等待：

    while ! ping -c1 1.1.1.1 &>/dev/null; do sleep 2; done echo "Network ready, starting..."

5.2 快速定位启动失败原因

系统启动日志藏在/tmp/或/var/log/下，但最直接的方法是：

logread | grep -i "rc\|testboot"

OpenWrt 中logread会输出全部内核+用户态日志，加上grep过滤关键词，往往一眼就能看到报错。

5.3 一键清理测试环境（防污染）

做完测试想还原？执行这三行：

rm -f /tmp/test_boot.log rm -f /etc/init.d/testboot rm -f /etc/rc.d/S99testboot

rc.local里的测试行，手动删掉即可。

6. 总结：开机启动这件事，其实就三步

你不需要记住所有命令，只要抓住核心逻辑，开机启动脚本就再也不会“失踪”：

  • 第一步：写一个能手动跑通的脚本
    无论用rc.local还是init.d，先确保它在命令行下能成功执行，并留下可验证痕迹（比如日志）。

  • 第二步：交给系统，但别盲目信任
    设权限、注册服务、手动触发一次，用status或ps看它是否真被系统“收编”。

  • 第三步：重启验证，用日志说话
    唯一可信的证据，是重启后/tmp/test_boot.log里那行新鲜的时间戳。其他都是推测。

现在，你可以合上屏幕，去你的设备上试一试了。从vi /etc/rc.local开始，敲下第一行echo，保存，设权限，重启——5 分钟后，你会收到系统发来的第一份“开机确认函”。

它不炫酷，但足够可靠。而这，正是工程落地最踏实的样子。

获取更多AI镜像

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

版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/4/16 12:36:48

Sambert语音项目落地：电商直播配音系统搭建案例

Sambert语音项目落地：电商直播配音系统搭建案例 1. 为什么电商直播间需要专属配音系统？ 你有没有注意过，现在刷抖音、淘宝直播时，那些卖衣服、卖零食、卖美妆的主播，语速快、情绪饱满、节奏感强，听起来特…

作者头像 李华
网站建设 2026/4/13 9:28:37

BERT轻量级优势凸显：移动端适配部署可行性分析

BERT轻量级优势凸显：移动端适配部署可行性分析 1. 什么是BERT智能语义填空服务 你有没有遇到过这样的场景：写文案时卡在某个成语中间，想不起后两个字；审校文章时发现一句“他做事非常认[MASK]”，却不确定该填“真”还…

作者头像 李华
网站建设 2026/4/17 13:03:42

如何解决百度网盘提取码获取难题：一款实用工具的深度解析

如何解决百度网盘提取码获取难题：一款实用工具的深度解析 【免费下载链接】baidupankey 项目地址: https://gitcode.com/gh_mirrors/ba/baidupankey 在数字资源交换日益频繁的今天，许多用户都曾面临这样的困境：当获取到一个百度网盘分…

作者头像 李华
网站建设 2026/4/18 3:45:39

告别机翻！这款Unity游戏翻译工具让外语游戏秒变中文

告别机翻！这款Unity游戏翻译工具让外语游戏秒变中文 【免费下载链接】XUnity.AutoTranslator 项目地址: https://gitcode.com/gh_mirrors/xu/XUnity.AutoTranslator 你是否也曾遇到这样的情况：明明看中一款好评如潮的日本独立游戏，却…

作者头像 李华
网站建设 2026/4/18 3:51:26

避坑指南：使用lama镜像常遇到的问题及解决方案

避坑指南：使用lama镜像常遇到的问题及解决方案 最近在多个图像修复项目中部署了 fft npainting lama重绘修复图片移除图片物品 二次开发构建by科哥 这个镜像，发现虽然它开箱即用、界面友好，但新手上手时仍容易踩进几类典型“深坑”——有些问…

作者头像 李华
网站建设 2026/4/18 3:50:14

Node.js用util.promisify搞定回调

💓 博客主页：瑕疵的CSDN主页 📝 Gitee主页：瑕疵的gitee主页 ⏩ 文章专栏：《热点资讯》 Node.js异步编程革命：利用util.promisify优雅解决回调地狱目录Node.js异步编程革命：利用util.promisify优…

作者头像 李华