5分钟搞定Linux开机自启，测试开机启动脚本保姆级教程
你是不是也遇到过这样的问题：写好了一个监控脚本、日志清理程序，或者一个简单的服务守护进程，每次重启服务器后都要手动运行一次？反复操作不仅费时，还容易遗漏——尤其在生产环境里，一次忘记可能就意味着服务中断。
别担心，Linux系统原生就支持开机自动执行脚本，而且不需要额外安装任何工具。本文将带你用最直接、最稳妥的方式，在5分钟内完成一个可验证、可复现、跨发行版通用的开机自启配置。全程不依赖systemd高级特性，兼容CentOS 7及更早版本、Ubuntu 16.04+（传统SysV init模式），也适用于当前仍使用/etc/init.d机制的嵌入式或轻量镜像环境——比如你正在使用的「测试开机启动脚本」镜像。
我们不讲抽象概念，不堆参数，只做三件事：
写一个真正能跑起来的测试脚本
让它在系统启动时自动执行
验证它确实生效了
现在就开始。
1. 编写一个可验证的测试脚本
所谓“保姆级”，第一步就是确保你写的脚本本身是可靠的。我们不追求复杂功能，只做一个清晰可见、结果可查的动作：在系统启动时，向指定文件写入一行带时间戳的日志。
打开终端，用root权限创建脚本：
sudo nano /etc/init.d/mytest.sh粘贴以下内容（注意保留#!/bin/bash开头）：
#!/bin/bash # chkconfig: 2345 99 01 # description: Simple test script for boot startup case "$1" in start) echo "[$(date '+%Y-%m-%d %H:%M:%S')] mytest.sh started at boot" >> /var/log/mytest_boot.log ;; stop) echo "[$(date '+%Y-%m-%d %H:%M:%S')] mytest.sh stopped" >> /var/log/mytest_boot.log ;; restart) $0 stop $0 start ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 ;; esac exit 0保存并退出（nano中按Ctrl+O → Enter → Ctrl+X）。
接下来赋予执行权限：
sudo chmod +x /etc/init.d/mytest.sh注意：这个脚本不是“一写完就自动运行”的魔法，它只是个待命的“演员”。下一步，我们要把它正式“请上舞台”。
2. 确认系统启动级别与对应rc目录
Linux传统启动流程中，不同运行级别（runlevel）会加载不同目录下的启动链接。虽然现代系统多用systemd，但绝大多数主流发行版（包括CentOS和Ubuntu）仍完整保留SysV init兼容层，而/etc/init.d/+/etc/rc*.d/正是其核心机制。
先确认你的系统当前默认运行级别：
runlevel输出类似N 5或3—— 第二个数字就是目标级别（5表示图形界面，3表示多用户文本模式）。绝大多数服务器环境为3或5；如果你不确定，直接查看默认目标：
sudo systemctl get-default 2>/dev/null || echo "SysV init mode (no systemd)"如果返回multi-user.target或graphical.target，说明底层仍通过/etc/rc3.d/或/etc/rc5.d/加载服务。
结论：无论输出是3还是5，我们都只需操作对应的/etc/rcX.d/目录即可。
小知识：
/etc/rcX.d/里的文件全是软链接，指向/etc/init.d/中的真实脚本。以S开头表示“Start”（启动），以K开头表示“Kill”（停止）。后面的两位数字决定执行顺序，比如S99mytest会在S20network之后、S98docker之前运行。
3. 将脚本注册到启动序列
现在进入关键一步：让系统知道“这个脚本要在开机时启动”。
我们不手动编辑/etc/rc.local（已逐步弃用且行为不稳定），也不用update-rc.d（Ubuntu专属，CentOS不支持），而是采用全发行版通用的手动软链法——简单、透明、无副作用。
假设你的runlevel显示为5（常见于桌面或带GUI的云镜像），执行：
cd /etc/rc5.d/ sudo ln -sf /etc/init.d/mytest.sh S99mytest如果显示为3（典型服务器环境），则改为：
cd /etc/rc3.d/ sudo ln -sf /etc/init.d/mytest.sh S99mytestln -sf中的-f表示“强制覆盖”，避免重复执行时报错；S99表示“最后启动”，确保它在基础网络、文件系统就绪后再运行，降低依赖失败风险。
验证是否成功：
ls -l S99mytest你应该看到类似输出：
S99mytest -> /etc/init.d/mytest.sh这说明链接已建立，系统启动时会自动调用/etc/init.d/mytest.sh start。
4. 手动触发一次启动，快速验证脚本逻辑
别急着重启！先手动运行一次，确认脚本本身没有语法错误、路径权限问题或逻辑缺陷。
sudo /etc/init.d/mytest.sh start然后检查日志是否写入：
cat /var/log/mytest_boot.log正常应输出类似：
[2024-06-15 10:23:45] mytest.sh started at boot如果能看到这行，说明脚本可执行、路径可写、时间戳准确——万事俱备。
❌ 如果报错，常见原因有：
/var/log/目录不存在 →sudo mkdir -p /var/log- 权限不足 →
sudo chown root:root /var/log/mytest_boot.log（首次需手动创建空文件） - 脚本语法错误 → 用
bash -n /etc/init.d/mytest.sh检查语法
修复后再试一次，直到日志成功写入。
5. 模拟重启前的最终检查清单
在真正重启前，请花30秒完成这几项确认，避免白等几分钟：
| 检查项 | 命令 | 预期结果 |
|---|---|---|
| 脚本存在且可执行 | ls -l /etc/init.d/mytest.sh | 权限含x（如-rwxr-xr-x） |
| 软链接存在且指向正确 | ls -l /etc/rc*.d/S99mytest | 显示-> /etc/init.d/mytest.sh |
| 日志目录可写 | `touch /var/log/mytest_boot.log 2>/dev/null && echo OK | |
| 启动级别匹配 | runlevel | awk '{print $2}' | 输出数字与你创建软链的rcX.d一致（如5→rc5.d） |
全部通过？可以放心重启了。
6. 重启验证 + 故障排查指南
执行重启命令：
sudo reboot等待系统重新上线后（SSH重连成功），立即检查日志：
tail -n 5 /var/log/mytest_boot.log正常情况：你会看到两条记录——一条是上次手动执行的，另一条是本次开机自动写入的，时间戳明显新于重启时刻。
❌ 如果只有旧记录，说明自启未生效。按以下顺序排查：
排查步骤1：确认软链接是否被覆盖
某些发行版（如Ubuntu）在安装服务时会自动运行update-rc.d，可能清空或重置/etc/rcX.d/。重新执行第3步的ln -sf命令，再检查链接是否存在。
排查步骤2：检查init脚本头部注释
SysV规范要求脚本顶部包含chkconfig行（我们已在第1步写入）：
# chkconfig: 2345 99 01该行告诉系统：“此脚本应在运行级别2、3、4、5启动，启动序号99，停止序号01”。缺失此行，部分系统可能忽略该脚本。
排查步骤3：查看系统启动日志
sudo dmesg \| grep -i "mytest\|init.d" 2>/dev/null || journalctl -b \| grep -i "mytest"寻找是否有mytest.sh: not found或Permission denied类报错。
排查步骤4：临时降级测试
如果仍失败，可尝试改用更通用的/etc/rc.local方式作为兜底（仅限调试）：
echo "/etc/init.d/mytest.sh start" | sudo tee -a /etc/rc.local sudo chmod +x /etc/rc.local注意：
/etc/rc.local在较新systemd系统中需额外启用，且优先级低于rcX.d。它仅作临时验证手段，不推荐长期使用。
7. 进阶建议：让脚本更健壮、更实用
你已经掌握了核心流程。下面这些小技巧，能让你的开机脚本从“能用”升级为“好用”：
添加服务状态管理（支持stop/restart）
我们在第1步脚本中已内置start/stop/restart分支。这意味着你可以随时手动控制：
sudo /etc/init.d/mytest.sh stop # 停止 sudo /etc/init.d/mytest.sh restart # 重启这对调试和维护至关重要。
设置日志轮转，避免日志撑爆磁盘
新建/etc/logrotate.d/mytest：
/var/log/mytest_boot.log { daily missingok rotate 7 compress delaycompress notifempty }这样每天自动归档，保留最近7天日志。
支持systemd兼容（双模保障）
如果你的系统同时支持SysV和systemd，可额外创建一个service单元文件，实现双重保障：
sudo tee /etc/systemd/system/mytest.service << 'EOF' [Unit] Description=My Test Boot Script After=network.target [Service] Type=oneshot ExecStart=/etc/init.d/mytest.sh start RemainAfterExit=yes [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable mytest.service这样即使未来系统升级，也能平滑过渡。
8. 总结：你刚刚完成了什么
回顾整个过程，你其实只做了四件小事，却构建了一套稳定可靠的自动化基础：
- 写了一个带生命周期管理的Shell脚本：支持start/stop/restart，输出可验证日志；
- 理解了Linux启动的本质路径：
/etc/init.d/是脚本存放地，/etc/rcX.d/是调度入口； - 用一条
ln -sf命令完成了注册：不修改系统配置，不依赖包管理器，零侵入； - 通过日志实现了100%可验证的结果：不是“看起来像启动了”，而是“确凿写入了时间戳”。
这套方法不挑发行版、不依赖新内核、不增加学习成本，是运维工程师、AI镜像开发者、边缘设备部署者真正需要的“最小可行自启方案”。
下次当你需要让模型加载服务、启动数据采集进程、或运行健康检查脚本时，记住：5分钟，一个脚本，一条软链，一份日志——就是全部。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
)
