news 2026/2/12 17:43:59

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

作者头像

张小明

前端开发工程师

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/2/4 13:44:58

IQuest-Coder-V1-40B-Instruct入门必看：本地部署完整步骤

IQuest-Coder-V1-40B-Instruct入门必看：本地部署完整步骤 IQuest-Coder-V1-40B-Instruct 面向软件工程和竞技编程的新一代代码大语言模型。 IQuest-Coder-V1是一系列新型代码大语言模型（LLMs），旨在推动自主软件工程和代码智能的发…

作者头像 李华
网站建设 2026/2/8 11:16:36

MinerU内存泄漏排查：长时间运行稳定性测试

MinerU内存泄漏排查：长时间运行稳定性测试 1. 背景与问题引入 在使用 MinerU 2.5-1.2B 深度学习 PDF 提取镜像进行大规模文档处理时，我们发现系统在长时间连续运行多个提取任务后出现显存占用持续上升、进程卡顿甚至崩溃的现象。这一行为初步判断为存在…

作者头像 李华
网站建设 2026/2/6 17:23:29

基于SpringBoot的小型医院医疗设备管理系统毕业设计源码

博主介绍：✌ 专注于Java,python,✌关注✌私信我✌具体的问题，我会尽力帮助你。 一、研究目的 本研究旨在开发一套基于SpringBoot框架的小型医院医疗设备管理系统，以实现医疗设备的高效管理、优化资源配置、提升医疗服务质量。具体研究目的如…

作者头像 李华
网站建设 2026/2/7 21:35:40

NewBie-image-Exp0.1推理显存超限？14-15GB占用应对策略实战分享

NewBie-image-Exp0.1推理显存超限？14-15GB占用应对策略实战分享 你是否在使用 NewBie-image-Exp0.1 时遇到显存不足、推理失败的问题？明明配置了高端显卡，却提示“CUDA out of memory”？别急——这并不是你的硬件不行&#xff0c…

作者头像 李华
网站建设 2026/2/12 7:33:47

实测分享：YOLO11在复杂场景下的检测效果

实测分享：YOLO11在复杂场景下的检测效果 1. 引言：为什么选择YOLO11做复杂场景检测？ 目标检测是计算机视觉中最核心的任务之一，而现实中的应用场景往往并不理想——遮挡严重、光照多变、目标密集、尺度差异大。在这些“复杂场景”…

作者头像 李华
网站建设 2026/2/6 0:35:23

OCR预处理怎么做？图像去噪增强配合cv_resnet18提效

OCR预处理怎么做？图像去噪增强配合cv_resnet18提效 1. 引言：为什么OCR前的图像预处理如此关键？ 你有没有遇到过这样的情况：一张照片里的文字明明看得清，但扔给OCR模型就是识别不出来？或者识别结果乱码、漏…

作者头像 李华