Linux运维入门：掌握最基本的自启脚本配置
你有没有遇到过这样的情况：服务器重启后，某个关键服务没起来，业务直接中断；或者每次开机都要手动执行一遍相同的命令，重复又容易出错？其实，Linux系统早就为你准备好了可靠的解决方案——开机自启脚本。它不依赖复杂工具，不需安装额外软件，只要几行清晰的配置，就能让系统在启动完成的第一时间自动执行你指定的任务。
这篇文章不是讲systemd服务单元文件的高级写法，也不是堆砌各种发行版差异的理论对比。它聚焦最核心、最通用、最稳妥的一条路径：用rc.local机制实现脚本自启。无论你是刚接触Linux的新手，还是需要快速验证方案的运维工程师，只要你会用终端、能看懂基础Shell命令，就能跟着一步步完成配置，并在重启后亲眼看到效果。我们不绕弯子，不讲抽象概念，只说“做什么”和“怎么做”。
1. 明确目标与适用场景
1.1 这个方法能解决什么问题
- 让一个Shell脚本在系统启动完成后自动运行（比如启动监控程序、初始化数据库连接、挂载网络存储）
- 无需编写复杂的systemd service文件，适合快速验证或临时需求
- 兼容性好，Ubuntu 16.04/18.04/20.04、Debian、CentOS 7等主流发行版均原生支持（部分新版系统需简单启用）
- 不依赖图形界面，纯命令行环境即可完成全部操作
1.2 它不适合哪些情况
- 需要严格控制服务启动顺序（如必须在MySQL之后、Nginx之前启动）
- 要求服务崩溃后自动重启（
rc.local只执行一次，失败不重试） - 多用户环境下需为不同用户分别配置（它属于系统级启动，对所有用户生效）
- 生产环境长期运行的关键服务（建议后续迁移到systemd管理）
一句话总结：这是Linux自启的“快捷键”，不是“操作系统”。它简单、直接、有效，是每个运维人员都该掌握的第一块基石。
2. 创建你的第一个自启脚本
2.1 选择存放位置与命名规范
脚本可以放在任何有执行权限的目录下，但为了清晰和安全，推荐统一存放在/opt/scripts/或/usr/local/bin/。这里我们使用/opt/scripts/，因为它专为本地自定义脚本设计，不易与系统文件混淆。
# 创建脚本目录（如果不存在） sudo mkdir -p /opt/scripts # 进入目录 cd /opt/scripts2.2 编写脚本内容
新建一个名为startup-check.sh的文件，内容如下：
#!/bin/bash # 记录启动时间，便于后续排查 echo "System started at $(date)" >> /var/log/startup-check.log # 执行一个简单但可验证的操作：创建一个带时间戳的测试文件 touch /tmp/startup-test-$(date +%s).tmp # 可选：启动一个后台小任务（例如监听端口） # nc -l 8080 < /dev/null > /dev/null 2>&1 & exit 0逐行说明：
#!/bin/bash是必需的“解释器声明”，告诉系统用bash来运行这个文件echo ... >> /var/log/...将日志追加写入系统日志目录，比写在当前目录更规范、更易查找touch ...创建一个带时间戳的空文件，重启后你只需ls /tmp/startup-test*就能立刻确认脚本是否执行exit 0表示脚本成功结束，这对rc.local机制很重要——它会检查脚本退出码，非0值可能导致后续启动流程异常
2.3 设置脚本执行权限
Linux默认不允许执行普通文件，必须显式赋予执行权：
sudo chmod +x /opt/scripts/startup-check.sh为什么不用
chmod 777？777意味着“所有人可读、可写、可执行”，这在生产环境中是严重安全隐患。+x只添加执行权限，保留原有读写权限，既安全又足够。
3. 启用并配置 rc.local 机制
3.1 检查 rc.local 是否存在并启用
在较新的Ubuntu（20.04+）或Debian系统中，rc.local默认被禁用。先确认状态：
sudo systemctl status rc-local如果显示inactive (dead)或报错Unit rc-local.service could not be found，说明需要手动启用。
启用步骤（一步到位）：
# 创建 rc.local 文件（如果不存在） sudo tee /etc/rc.local << 'EOF' #!/bin/bash # 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 # ./startup-check.sh exit 0 EOF # 设置执行权限 sudo chmod +x /etc/rc.local # 启用 systemd 服务 sudo systemctl enable rc-local sudo systemctl start rc-local这段命令做了三件事：创建标准格式的rc.local文件、赋予执行权限、并通过systemd启用它。完成后，sudo systemctl status rc-local应显示active (exited)。
3.2 在 rc.local 中调用你的脚本
现在编辑/etc/rc.local，在exit 0之前插入你的脚本调用：
sudo nano /etc/rc.local将以下两行添加到exit 0上方：
cd /opt/scripts ./startup-check.sh注意：
- 必须用
cd切换到脚本所在目录再执行，避免因路径问题导致脚本内部相对路径失效 - 不要用
sudo ./startup-check.sh——rc.local本身就在root权限下运行，重复sudo反而可能引发权限冲突
保存并退出（nano中按Ctrl+O→ 回车 →Ctrl+X）。
4. 验证配置是否生效
4.1 不重启的快速验证方法
与其反复重启，不如先模拟rc.local的执行环境：
# 以root身份直接运行 rc.local sudo /etc/rc.local # 检查日志是否写入 sudo tail -n 3 /var/log/startup-check.log # 检查测试文件是否生成 ls -t /tmp/startup-test-*.tmp | head -n 1如果日志里有时间记录，且/tmp下出现了新文件，说明脚本本身和rc.local调用逻辑完全正确。
4.2 最终验证：重启系统
sudo reboot等待系统完全启动后，登录终端，执行：
# 查看日志末尾，确认本次启动被记录 sudo tail -n 5 /var/log/startup-check.log # 列出所有 startup-test 文件，最新那个就是本次重启生成的 ls -lt /tmp/startup-test-*.tmp | head -n 1如果输出中包含类似startup-test-1715678901.tmp的文件名，且时间戳与你重启时间吻合，恭喜你，自启脚本已稳定运行。
5. 常见问题与排错指南
5.1 脚本执行了，但日志为空或文件没生成
最常见原因是路径错误。rc.local在系统早期启动阶段运行，此时某些挂载点（如/home、/mnt）可能尚未就绪。解决方案：
- 将脚本和日志路径统一放在系统根分区下（如
/opt/scripts/、/var/log/），避开用户目录和外部存储 - 在脚本开头加入延迟或等待逻辑（仅限调试）：
# 等待网络就绪（可选） while ! ping -c1 google.com &>/dev/null; do sleep 2 done5.2 Ubuntu 22.04+ 提示 “Failed to start /etc/rc.local Compatibility”
这是因为新版Ubuntu彻底移除了rc.local支持。此时有两个选择：
方案一（推荐）：改用 systemd 服务（轻量版）
# 创建服务文件 sudo tee /etc/systemd/system/startup-check.service << 'EOF' [Unit] Description=Startup Check Script After=multi-user.target [Service] Type=oneshot ExecStart=/opt/scripts/startup-check.sh RemainAfterExit=yes [Install] WantedBy=multi-user.target EOF # 启用并启动 sudo systemctl daemon-reload sudo systemctl enable startup-check.service sudo systemctl start startup-check.service方案二（兼容旧习惯）：临时启用 rc.local
参考第3.1节中的启用命令，它在22.04上同样有效，只是需要手动创建文件。
5.3 如何修改或停用已配置的自启
- 修改脚本：直接编辑
/opt/scripts/startup-check.sh，保存后无需其他操作，下次启动即生效 - 临时禁用：注释掉
/etc/rc.local中的调用行（在前面加#） - 永久删除：删除
/etc/rc.local中的调用行，并运行sudo systemctl disable rc-local（如果用的是systemd方式）
6. 总结：从入门到可靠落地的三个关键认知
6.1 理解本质，而非死记步骤
rc.local不是一个神秘黑盒，它只是系统在完成所有基础服务启动后，按顺序执行的最后一段“用户自定义代码”。它的价值在于时机确定、权限充足、逻辑简单。掌握这一点，你就不会纠结于“为什么一定要放/etc/下”，而会自然想到：“我需要它在哪个阶段运行？需要什么权限？会不会影响其他服务？”
6.2 日志是排错的唯一真相
永远不要靠“应该执行了”来判断成功。每一行echo、每一个touch，都是你与系统之间的信使。把日志写进/var/log/，而不是当前目录或/tmp，是专业运维的第一课。
6.3 从小处着手，建立可验证的闭环
本文的整个流程就是一个最小可行闭环：写脚本 → 设权限 → 配rc.local → 验证日志 → 重启确认。它不追求功能丰富，只确保每一步都有明确输入、可观察输出、可重复验证。这种思维模式，比记住一百个命令更重要。
你现在拥有的，不仅是一个能开机自启的脚本，更是一把打开Linux自动化世界大门的钥匙。下一步，你可以尝试让它启动一个Python Web服务，或者定时同步远程数据——而所有这些，都建立在今天你亲手配置成功的这个坚实基础上。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
