系统重启后服务自动拉起，我是这样配置的
在实际生产环境中，确保关键服务在系统重启后能够自动启动是运维工作的基本要求。本文将详细介绍如何通过传统的 SysVinit 机制实现服务的开机自启，适用于 CentOS 和 Ubuntu 等主流 Linux 发行版。我们将从脚本准备、运行级别分析到软链接创建，完整走一遍配置流程，并提供可落地的实践建议。
1. 准备自启动脚本
要实现服务开机自启，首先需要编写一个符合 init 脚本规范的 Shell 脚本。该脚本通常放置在/etc/init.d/目录下，这是传统 SysVinit 系统中存放服务启动脚本的标准路径。
1.1 编写基础启动脚本
以下是一个示例脚本mytest.sh，用于模拟一个后台服务的启动与停止：
#!/bin/bash # # mytest.sh 启动一个测试服务 # description: 测试开机启动功能的服务脚本 SERVICE_NAME="MyTestService" PID_FILE="/var/run/mytest.pid" LOG_FILE="/var/log/mytest.log" case "$1" in start) echo "Starting $SERVICE_NAME..." if [ -f $PID_FILE ]; then echo "$SERVICE_NAME is already running." exit 1 fi # 模拟后台进程 nohup sh -c 'while true; do echo "$(date): Heartbeat" >> /tmp/mytest.log; sleep 10; done' & echo $! > $PID_FILE echo "$SERVICE_NAME started." ;; stop) echo "Stopping $SERVICE_NAME..." if [ ! -f $PID_FILE ]; then echo "$SERVICE_NAME is not running." exit 1 fi kill $(cat $PID_FILE) > /dev/null 2>&1 rm -f $PID_FILE echo "$SERVICE_NAME stopped." ;; restart) $0 stop $0 start ;; status) if [ -f $PID_FILE ]; then if kill -0 $(cat $PID_FILE) > /dev/null 2>&1; then echo "$SERVICE_NAME is running with PID $(cat $PID_FILE)" else echo "$SERVICE_NAME is not running (stale PID file)" rm -f $PID_FILE fi else echo "$SERVICE_NAME is not running" fi ;; *) echo "Usage: $0 {start|stop|restart|status}" exit 1 ;; esac exit 01.2 设置脚本权限并注册为服务
将脚本保存为/etc/init.d/mytest.sh，然后赋予可执行权限：
sudo chmod +x /etc/init.d/mytest.sh此时即可手动测试脚本是否正常工作：
sudo /etc/init.d/mytest.sh start sudo /etc/init.d/mytest.sh status sudo /etc/init.d/mytest.sh stop2. 查看系统运行级别
Linux 系统使用“运行级别”（Runlevel）来定义不同的系统状态。SysVinit 根据当前运行级别决定加载哪些服务。
2.1 使用 runlevel 命令查看当前级别
执行以下命令查看最后一次和当前的运行级别：
runlevel输出示例如下：
N 5其中： -N表示之前无运行级别（即刚开机） -5表示当前运行级别为 5
常见运行级别含义如下：
| 运行级别 | 说明 |
|---|---|
| 0 | 关机 |
| 1 | 单用户模式 |
| 2 | 多用户模式（无网络） |
| 3 | 多用户模式（命令行） |
| 4 | 用户自定义 |
| 5 | 多用户模式 + 图形界面 |
| 6 | 重启 |
大多数服务器环境默认运行在级别 3 或 5。
3. 理解 rc.d 目录结构
SysVinit 在系统启动时会根据运行级别进入对应的/etc/rcX.d/目录（X 为运行级别），并按顺序执行其中的脚本链接。
3.1 目录作用说明
/etc/init.d/：存放所有服务的实际启动脚本。/etc/rcX.d/：每个运行级别对应的脚本链接目录，内容为指向/etc/init.d/的软链接。
3.2 链接命名规则
rcX.d 目录中的文件名遵循特定格式：[S/K][0-9][0-9][service_name]
| 前缀 | 含义 |
|---|---|
| S | Start，在系统启动时执行 |
| K | Kill，在系统关闭时执行 |
| 数字 | 执行顺序（00~99），数值越小越早执行 |
例如： -S80apache2：在启动时第 80 顺位启动 Apache 服务 -K20mysql：在关机时第 20 顺位停止 MySQL 服务
4. 创建软链接实现开机自启
确定运行级别后，需在对应 rc 目录中创建指向/etc/init.d/mytest.sh的软链接。
4.1 进入目标 rc 目录
假设当前运行级别为 5，则进入：
cd /etc/rc5.d/注意：若系统使用 systemd（如较新版本的 Ubuntu/CentOS），此方法仍兼容，但推荐使用
systemctl enable替代。
4.2 创建启动软链接
使用ln命令创建以S开头的软链接，表示开机启动：
sudo ln -s /etc/init.d/mytest.sh S99mytest参数解释：
/etc/init.d/mytest.sh：源脚本路径S99mytest：软链接名称S：表示启动时执行99：执行顺序编号，设为较大值以确保依赖服务（如数据库、网络）已就绪mytest：服务名称标识
4.3 验证软链接是否生效
列出目录内容确认链接存在：
ls -l /etc/rc5.d/S99mytest预期输出：
lrwxrwxrwx 1 root root 24 Apr 5 10:00 S99mytest -> /etc/init.d/mytest.sh5. 测试与验证
完成配置后，通过重启系统验证服务是否能自动拉起。
5.1 重启系统
sudo reboot5.2 登录后检查服务状态
系统重启后，立即检查服务运行情况：
sudo /etc/init.d/mytest.sh status如果看到类似输出：
MyTestService is running with PID 1234说明服务已成功自动启动。
5.3 查看日志确认行为
检查我们脚本写入的日志文件：
tail /tmp/mytest.log应能看到周期性的心跳记录，证明后台进程持续运行。
6. 实践优化与注意事项
虽然上述方法在多数场景下有效，但在实际工程中还需注意以下几点。
6.1 合理设置启动顺序
若服务依赖数据库、Redis 或其他中间件，应将其启动序号设置为较高值（如 90 以上），确保依赖项已准备就绪。
示例：
# 推荐做法：晚于大多数服务启动 sudo ln -s /etc/init.d/mytest.sh S95mytest6.2 兼容现代系统（systemd）
对于使用systemd的系统（CentOS 7+、Ubuntu 16.04+），更推荐使用systemctl方式管理服务。
创建 unit 文件：
# /etc/systemd/system/mytest.service [Unit] Description=My Test Service After=network.target [Service] ExecStart=/etc/init.d/mytest.sh start ExecStop=/etc/init.d/mytest.sh stop Restart=always Type=forking PIDFile=/var/run/mytest.pid [Install] WantedBy=multi-user.target启用开机自启：
sudo systemctl daemon-reexec sudo systemctl enable mytest.service sudo systemctl start mytest.service这种方式更加标准化，支持依赖管理、自动重启、日志集成等高级特性。
6.3 安全性建议
- 最小权限原则：避免以 root 身份长期运行服务，可在脚本中切换用户。
- 日志轮转：使用
logrotate管理日志文件，防止磁盘占满。 - 异常恢复：考虑加入监控脚本或配合
cron定期检查进程状态。
7. 总结
本文详细介绍了如何通过 SysVinit 机制实现 Linux 系统中服务的开机自启，涵盖脚本编写、运行级别识别、rc.d 软链接创建及验证全流程。核心要点包括：
- 脚本规范：
/etc/init.d/下的脚本需支持start、stop、status等标准操作； - 运行级别匹配：根据
runlevel输出选择正确的/etc/rcX.d/目录； - 软链接命名：使用
S[0-9][0-9][name]格式创建启动链接，数字越大启动越晚； - 顺序控制：关键服务应设置较高序号，确保依赖服务已启动；
- 现代替代方案：在支持
systemd的系统上，优先使用systemctl enable实现更可靠的管理。
尽管 SysVinit 正逐步被 systemd 取代，但在许多遗留系统或嵌入式环境中仍广泛使用。掌握这一机制有助于应对多样化的部署场景，提升系统的稳定性和自动化能力。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
