测试开机启动脚本配置全流程，一步不错过

测试开机启动脚本配置全流程，一步不错过

你是不是也遇到过这样的问题：写好了自动化脚本，测试运行没问题，可一重启就“失联”？明明设置了开机自启，却始终没看到预期效果——日志没生成、程序没启动、文件没写入。别急，这不是脚本的问题，大概率是开机启动配置的某个环节被跳过了。

本文不讲抽象原理，不堆术语，只带你从零开始、手把手走完完整流程，每一步都明确说明“为什么这么做”“不做会怎样”“怎么验证成功”。无论你是刚接触Linux的新手，还是被rc.local权限折腾过的老手，只要跟着做，就能让脚本真正在系统启动时稳稳跑起来。

全文基于主流Ubuntu环境（18.04及以上兼容），所有操作均经实测验证，覆盖常见坑点：脚本权限不足、rc.local不可写、路径失效、执行用户错位、缺少退出码等。文末还附上快速排查清单和替代方案，确保你一次配对，长期稳定。

1. 创建可执行脚本：不只是写代码，更要写对位置和内容

开机启动脚本不是随便放哪都行，也不是写完保存就完事。它必须满足三个基本条件：有明确路径、有正确语法、有实际输出验证点。我们以一个轻量但功能完整的测试脚本为例，全程在终端中完成，避免图形界面干扰。

1.1 在标准路径下新建脚本文件

推荐将脚本放在/opt/scripts/目录下（比/home/user/...更规范，不受用户主目录影响）。如果该目录不存在，先创建：

sudo mkdir -p /opt/scripts sudo chown $USER:$USER /opt/scripts

接着创建脚本文件auto_run_test.sh：

nano /opt/scripts/auto_run_test.sh

粘贴以下内容（注意：使用英文引号，不要复制网页中的中文标点）：

#!/bin/bash # 记录启动时间戳，用于区分多次启动 echo "=== System Boot at $(date) ===" >> /var/log/auto_run_test.log echo "Script executed by: $(whoami)" >> /var/log/auto_run_test.log # 进入指定工作目录（此处用 /tmp 演示，避免权限问题） cd /tmp echo "Current working directory: $(pwd)" >> /var/log/auto_run_test.log # 创建一个带时间标记的测试文件，证明脚本确实运行了 touch test_boot_$(date +%s).txt echo "Test file created successfully." >> /var/log/auto_run_test.log # 模拟一个简单命令（如检查网络连通性） ping -c 1 8.8.8.8 > /dev/null 2>&1 && echo "Network OK" || echo "Network FAIL" >> /var/log/auto_run_test.log exit 0

关键说明

• 第一行#!/bin/bash是必需的“解释器声明”，告诉系统用 bash 执行此脚本；缺了它，系统可能用 sh 执行，导致语法报错。
• 所有日志写入/var/log/而非当前目录，因为开机时当前路径不确定，而/var/log/是系统级可写目录。
• 使用$(date +%s)生成时间戳，避免文件名冲突；>>是追加写入，方便查看多次启动记录。
• 最后的exit 0表示脚本成功结束——这对 rc.local 至关重要，否则系统可能中断后续启动流程。

1.2 验证脚本能否手动运行

别急着设开机启动，先确认脚本本身没问题：

chmod +x /opt/scripts/auto_run_test.sh /opt/scripts/auto_run_test.sh

然后检查日志是否生成：

tail -n 5 /var/log/auto_run_test.log

你应该看到类似这样的输出：

=== System Boot at Mon Jun 10 14:22:35 CST 2024 === Script executed by: yourusername Current working directory: /tmp Test file created successfully. Network OK

如果能看到完整输出，说明脚本语法正确、路径可访问、权限足够。
❌ 如果报错“Permission denied”，说明权限没加；报错“No such file”，说明路径写错；报错“command not found”，检查是否漏了#!/bin/bash。

2. 设置脚本执行权限：777不是万能解，644才是安全起点

很多教程直接教sudo chmod 777，看似省事，实则埋下安全隐患：777 表示“所有人可读可写可执行”，一旦脚本被恶意篡改，攻击者就能获得最高权限。对测试脚本而言，644（所有者可读写，组和其他人只读）+ 所有者执行权更合理。

执行以下命令：

sudo chmod 644 /opt/scripts/auto_run_test.sh sudo chmod u+x /opt/scripts/auto_run_test.sh

等价于chmod 744—— 所有者可读写执行，组和其他人仅可读。既保证脚本能被执行，又杜绝未授权修改。

为什么不用 755？
755 允许组和其他人执行，但开机启动时脚本由 root 执行，普通用户无需执行权限；保留只读更清晰，也符合最小权限原则。

验证权限是否生效：

ls -l /opt/scripts/auto_run_test.sh

输出应类似：

-rwxr--r-- 1 yourusername yourusername 528 Jun 10 14:20 /opt/scripts/auto_run_test.sh

其中-rwxr--r--表示：所有者（rwx）可读写执行，组（r--）和其他人（r--）仅可读。

3. 启用并配置 rc.local：不是“改文件就行”，而是“激活服务+写对内容”

Ubuntu 16.04 之后，rc.local默认不再启用，即使你编辑了文件，系统也不会自动执行它。必须先启用 systemd 的 rc-local 服务，再配置内容，两步缺一不可。

3.1 创建并启用 rc-local 服务

首先检查/etc/rc.local是否存在：

ls -l /etc/rc.local

如果提示 “No such file”，手动创建：

sudo nano /etc/rc.local

输入以下标准模板（注意：必须包含#!/bin/sh -e和exit 0）：

#!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. # Your commands here cd /opt/scripts ./auto_run_test.sh exit 0

关键细节

• 第一行#!/bin/sh -e中的-e表示“任一命令失败即退出”，防止后续命令误执行。
• cd /opt/scripts必须写全路径，不能用~或$HOME，因为开机时环境变量未完全加载。
• 调用脚本用./auto_run_test.sh（相对路径），而非/opt/scripts/auto_run_test.sh（绝对路径），更简洁且不易出错。
• exit 0必须在文件末尾，且独占一行——这是 rc.local 的硬性要求，缺了会导致启动卡住。

保存后，设置可执行权限：

sudo chmod +x /etc/rc.local

3.2 启用 systemd 的 rc-local 服务

Ubuntu 使用 systemd 管理服务，需显式启用rc-local：

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

检查服务状态：

sudo systemctl status rc-local

正常输出应包含active (exited)和Loaded: loaded (/etc/systemd/system/rc-local.service; enabled)。如果显示failed，常见原因是/etc/rc.local缺少exit 0或语法错误，用sudo journalctl -u rc-local查看具体报错。

4. 替代方案：当 rc.local 不可用时，systemd 服务更可靠

部分精简版 Ubuntu 或云服务器镜像（如某些 Docker 容器基础镜像）压根不带rc.local。此时，原生 systemd 服务是更现代、更可控的选择，且无需依赖已废弃的机制。

4.1 创建专用 service 文件

sudo nano /etc/systemd/system/auto-run-test.service

填入以下内容：

[Unit] Description=Auto-run Test Script at Boot After=multi-user.target [Service] Type=oneshot ExecStart=/opt/scripts/auto_run_test.sh RemainAfterExit=yes User=root [Install] WantedBy=multi-user.target

参数解析

• Type=oneshot：表示脚本执行完即退出，适合一次性任务。
• RemainAfterExit=yes：让服务状态保持“active”，便于后续用systemctl status查看是否成功运行。
• User=root：明确指定以 root 权限运行，避免因权限不足导致失败。
• After=multi-user.target：确保在网络、文件系统等基础服务就绪后再执行。

保存后，重载 systemd 配置并启用服务：

sudo systemctl daemon-reload sudo systemctl enable auto-run-test.service sudo systemctl start auto-run-test.service

验证是否生效：

sudo systemctl status auto-run-test.service

应显示active (exited)，且journalctl中能看到脚本输出：

sudo journalctl -u auto-run-test.service -n 10 --no-pager

此方案优势明显：不依赖 rc.local、权限控制精细、日志统一管理、启用/禁用一键切换。

5. 重启验证与问题排查：不靠猜，靠日志和分步确认

配置完成后，必须重启验证。切忌只看“没报错”就认为成功——开机启动的上下文和手动执行完全不同。

5.1 执行重启并等待完成

sudo reboot

等待系统完全启动，登录后立即检查：

# 查看日志是否写入 sudo tail -n 20 /var/log/auto_run_test.log # 检查测试文件是否生成 ls -lt /tmp/test_boot_*.txt | head -n 3 # 检查 rc-local 服务状态（如果用了该方案） sudo systemctl status rc-local # 检查 systemd 服务状态（如果用了该方案） sudo systemctl status auto-run-test.service

成功标志：日志中有本次重启的时间戳，/tmp/下有新生成的test_boot_*.txt文件，服务状态为active (exited)。

5.2 常见失败原因与速查清单

终极调试技巧：在脚本开头添加set -x，它会让 bash 打印每条执行的命令，帮你精准定位卡在哪一步：

#!/bin/bash set -x # 开启调试模式 echo "debug: starting..." >> /var/log/auto_run_test.log # ... 其余内容

6. 总结：开机启动不是玄学，是可验证的工程动作

回看整个流程，你会发现所谓“一步不错过”，其实就落在五个确定性动作上：

• 脚本本身可验证：有日志、有文件、有时间戳，不靠“感觉”判断是否运行；
• 权限设置有依据：不用777，用644+u+x，兼顾可用性与安全性；
• rc.local 是服务，不是文件：启用systemctl enable rc-local比改文件更重要；
• systemd 是首选方案：尤其在新系统或容器环境中，它更健壮、更透明；
• 重启后必查日志：/var/log/是你的第一现场，journalctl是最准的证人。

你不需要记住所有命令，只需建立一个检查习惯：每次配置后，问自己三个问题——
① 脚本手动运行是否成功？
② 服务/脚本是否处于 active 状态？
③/var/log/里有没有本次启动的痕迹？

做到这三点，开机启动就再也不是黑盒，而是一个清晰、可控、可重复的工程环节。

--- > **获取更多AI镜像** > > 想探索更多AI镜像和应用场景？访问 [CSDN星图镜像广场](https://ai.csdn.net/?utm_source=mirror_blog_end)，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。