news 2026/4/17 17:52:50

测试开机启动脚本使用心得：稳定可靠易部署

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
测试开机启动脚本使用心得：稳定可靠易部署

测试开机启动脚本使用心得：稳定可靠易部署

在实际项目开发和系统运维过程中，经常会遇到需要让某些服务或任务在系统启动时自动运行的需求。比如自定义监控脚本、后台服务初始化、硬件设备检测等场景。如果每次重启后都要手动执行命令，不仅效率低下，还容易遗漏关键步骤。

最近我在使用“测试开机启动脚本”这一镜像环境时，深入实践了Linux系统下的开机自启方案，结合Ubuntu系统的特性，总结出一套稳定、可靠、易部署的脚本启动方法。本文将从实际操作出发，手把手带你完成整个流程，并分享我在部署过程中的真实体验与优化建议。

1. 明确目标：我们想实现什么？

在开始之前，先明确我们的核心需求：

  • 编写一个自定义的Shell脚本（.sh文件）
  • 让这个脚本在每次系统开机时自动执行
  • 脚本能正确访问指定路径、运行程序并输出日志
  • 整个方案要稳定，不因系统更新而失效
  • 部署方式简单，适合批量复制到多台设备

这正是“测试开机启动脚本”镜像所要验证的核心功能。接下来我会基于Ubuntu类系统（如18.04及以上版本）进行说明，但大部分逻辑也适用于其他Debian系发行版。

2. 创建自定义启动脚本

第一步是编写我们要自动运行的Shell脚本。选择一个合适的存放位置非常重要，推荐放在用户主目录下的专用脚本文件夹中，便于管理。

2.1 建立脚本目录与文件

mkdir -p ~/scripts nano ~/scripts/auto_run_test.sh

然后输入以下内容：

#!/bin/bash # 输出启动标记 echo "helloStartup" > ~/scripts/output.txt # 进入目标工程目录 cd /home/user/mywbc_v5_usb/build || exit 1 echo "EnterBuildDir" >> ~/scripts/output.txt # 启动模拟程序 ./sim/sim & # 标记执行完成 echo "AfterSim" >> ~/scripts/outputend.txt

2.2 关键细节说明

  • #!/bin/bash：声明解释器，必须写在第一行
  • >>而不是>：追加写入日志，避免覆盖前面的日志信息
  • &符号：让sim程序以后台模式运行，防止阻塞系统启动
  • || exit 1：增强健壮性，若目录不存在则退出脚本

保存并退出编辑器（Ctrl+O → Enter → Ctrl+X）。

3. 设置脚本可执行权限

Linux默认不会执行没有权限的脚本。我们需要赋予它执行权限：

chmod +x ~/scripts/auto_run_test.sh

也可以使用更宽松的权限（如参考文档中的777），但在生产环境中建议最小化权限原则：

sudo chmod 755 ~/scripts/auto_run_test.sh

此时你可以手动测试一下脚本是否能正常运行：

~/scripts/auto_run_test.sh cat ~/scripts/output.txt

确保能看到"helloStartup"和"EnterBuildDir"的输出，说明脚本本身没问题。

4. 利用 rc.local 实现开机自启（经典可靠方案）

Ubuntu早期版本广泛使用的rc.local是最简单且兼容性强的开机启动方式之一。虽然新版本系统逐渐转向 systemd，但通过适当配置仍可完美支持。

4.1 检查 rc.local 是否存在

ls /etc/rc.local

如果提示文件不存在，需要手动创建。

4.2 创建并编辑 rc.local 文件

sudo nano /etc/rc.local

填入以下内容：

#!/bin/sh -e # 开机自启脚本入口 cd /home/user/scripts && sudo sh auto_run_test.sh # 必须以 exit 0 结尾 exit 0

注意：这里的/home/user/scripts需根据实际用户名调整路径。

4.3 设置 rc.local 可执行

为了让系统识别并执行该脚本，必须设置其权限并启用服务：

sudo chmod +x /etc/rc.local

对于使用 systemd 的系统（Ubuntu 16.04+），还需确保rc-local.service已启用：

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

查看状态确认是否成功：

sudo systemctl status rc-local

如果看到active (exited)表示已正常加载。

5. 替代方案：写入 /etc/profile（适用于桌面环境）

如果你发现rc.local不生效，或者使用的是某些精简版系统（如部分云镜像或容器环境），可以考虑将命令追加到全局环境配置文件中。

5.1 修改 profile 文件

sudo nano /etc/profile

在文件末尾添加：

# 自动运行测试脚本 if [ -f /home/user/scripts/auto_run_test.sh ]; then sh /home/user/scripts/auto_run_test.sh fi

这种方式的优点是：

  • 几乎所有Linux系统都支持/etc/profile
  • 用户登录时自动触发，适合带GUI的应用

缺点也很明显：

  • 只有用户登录后才会执行
  • 多用户环境下可能重复执行
  • 不适合无界面的服务器场景

因此，仅作为备用方案推荐。

6. 实际测试与结果验证

一切配置完成后，最关键的一步来了：重启系统！

sudo reboot

等待系统重新启动后，检查日志文件是否存在且内容完整：

cat ~/scripts/output.txt cat ~/scripts/outputend.txt

预期输出应包含：

helloStartup EnterBuildDir AfterSim

同时可以用ps命令查看sim进程是否正在运行：

ps aux | grep sim

如果能看到进程存在，说明脚本已成功启动目标程序。

7. 常见问题与解决方案

在实际部署过程中，我遇到了几个典型问题，这里一并分享解决方法。

7.1 脚本路径错误导致找不到文件

现象：日志为空或提示“no such file or directory”

原因：rc.local是以 root 身份运行的，工作目录不一定是你期望的路径。

解决方案：在脚本中使用绝对路径，或显式切换目录：

cd "$(dirname "$0")" # 切换到脚本所在目录

或者直接在rc.local中指定完整路径：

su - user -c "sh /home/user/scripts/auto_run_test.sh"

这样可以以特定用户身份运行脚本，避免权限问题。

7.2 程序启动太快导致依赖未就绪

现象：./sim/sim报错无法连接设备或共享库缺失

原因：系统刚启动时，USB设备、网络、挂载点等尚未准备就绪。

解决方案：加入短暂延迟或等待机制：

sleep 5 until ping -c1 google.com &>/dev/null; do sleep 1; done # 等待网络

或者循环检测关键设备是否存在：

while [ ! -d "/home/user/mywbc_v5_usb/build" ]; do sleep 1 done

7.3 日志文件权限不足

现象：脚本能运行，但日志写不进去

原因：root运行脚本，试图写普通用户的家目录

解决方案：要么改用用户身份运行，要么将日志写入公共目录：

echo "helloStartup" > /tmp/startup.log

或者修改目标目录权限：

chmod 777 ~/scripts/

（仅用于调试，生产环境慎用）

8. 进阶建议：提升稳定性与可维护性

经过多次部署测试，我发现以下几个小技巧能让整个方案更加稳健。

8.1 添加时间戳记录启动时刻

在脚本开头加入时间记录，方便排查问题：

echo "[$(date '+%Y-%m-%d %H:%M:%S')] System boot script started" >> ~/scripts/boot.log

8.2 使用 nohup 防止被中断

即使在后台运行，某些情况下进程仍可能被终止。使用nohup更安全：

nohup ./sim/sim > /tmp/sim.log 2>&1 &

8.3 加入守护判断防止重复启动

防止脚本被多次调用导致多个实例冲突：

LOCKFILE=/tmp/auto_run_test.lock if [ -f "$LOCKFILE" ]; then echo "Script already running" exit 1 fi touch "$LOCKFILE" # ... 主逻辑 ... rm -f "$LOCKFILE"

8.4 统一管理多个启动任务

如果有多个脚本需要开机运行，建议统一放在/opt/boot-scripts/目录下，并由一个主控脚本调度：

# /opt/boot-scripts/main.sh for script in /opt/boot-scripts/*.sh; do [ -x "$script" ] && "$script" done

然后只在rc.local中调用这一个主脚本，结构更清晰。

9. 总结：为什么这套方案值得推荐？

经过反复验证，“测试开机启动脚本”镜像所体现的这套基于rc.local的启动机制，具备以下几个显著优势：

9.1 稳定性高

  • rc.local是传统Unix/Linux的标准组件之一
  • 即使系统升级，只要保留兼容层就能继续使用
  • 执行时机在系统基本服务启动之后，资源可用性高

9.2 部署简单

  • 不需要编写复杂的systemd unit文件
  • 脚本结构清晰，易于理解和维护
  • 支持快速复制到多台设备，适合嵌入式或边缘计算场景

9.3 兼容性强

  • 适用于Ubuntu 16.04 ~ 22.04等多个版本
  • 在树莓派、NVIDIA Jetson、工业PC等设备上均可运行
  • 可与其他自动化工具（Ansible、SaltStack）集成

9.4 易于调试

  • 日志输出直观，便于定位问题
  • 可随时手动执行脚本进行测试
  • 错误反馈明确，无需深入systemd日志系统

获取更多AI镜像

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

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

从扫描件到结构化数据｜PaddleOCR-VL-WEB助力企业文档智能处理

从扫描件到结构化数据｜PaddleOCR-VL-WEB助力企业文档智能处理 在企业日常运营中，每天都会产生大量纸质文件、PDF扫描件或图像格式的合同、发票、报表和产品说明书。这些文档承载着关键业务信息，但因为是非结构化的图像数据，难以被…

作者头像 李华
网站建设 2026/4/10 18:35:05

图像修复精度提升：fft npainting lama小画笔使用心得

图像修复精度提升：fft npainting lama小画笔使用心得 在图像处理领域，精准、自然地移除不需要的元素一直是用户的核心需求。传统的图像修复工具往往依赖复杂的操作流程或昂贵的专业软件，而如今基于深度学习的AI修复技术正在改变这一局面。本…

作者头像 李华
网站建设 2026/4/11 11:39:22

DeepSeek-OCR大模型实战｜基于DeepSeek-OCR-WEBUI快速部署与网页推理

DeepSeek-OCR大模型实战｜基于DeepSeek-OCR-WEBUI快速部署与网页推理 1. 引言：为什么你需要关注这款国产OCR大模型？ 你有没有遇到过这样的场景：一堆纸质发票、合同、身份证需要录入系统，手动打字慢不说，还…

作者头像 李华
网站建设 2026/4/16 14:22:37

AI语音降噪新选择｜FRCRN单麦16k镜像部署与推理全解析

AI语音降噪新选择｜FRCRN单麦16k镜像部署与推理全解析 在远程会议、在线教学或录音创作中，环境噪音常常成为影响语音质量的“隐形杀手”。你是否也遇到过背景风扇声盖过人声、街道嘈杂干扰通话清晰度的问题？现在，借助AI技术&#…

作者头像 李华
网站建设 2026/4/16 12:10:25

SenseVoice Small语音识别实战｜一键部署中文情感与事件标签检测

SenseVoice Small语音识别实战｜一键部署中文情感与事件标签检测 1. 快速上手：从零开始体验语音智能分析 你有没有遇到过这样的场景？一段客户电话录音，既要转成文字，又要判断对方是满意还是抱怨，还得知道里…

作者头像 李华