Rocky Linux 10.0开机自启动配置实战：systemd与rc.local对比

1. Rocky Linux 10.0 开机自启动方案深度解析

在Linux系统管理中，服务开机自启动是一个基础但至关重要的需求。最近我在Rocky Linux 10.0系统上为keepalived_web.sh脚本配置开机自启动时，经历了一番探索和尝试。本文将详细记录整个过程，包括两种主流方案的对比、具体实现步骤以及背后的技术原理。

1.1 系统环境与需求说明

系统环境：

• 操作系统：Rocky Linux 10.0（基于RHEL 10.0）
• 初始化系统：systemd（现代Linux发行版的标准）
• 脚本位置：/opt/paraview/esc/bin/keepalived_web.sh

核心需求：

1. 系统启动时自动执行keepalived_web.sh脚本
2. 确保脚本以root权限运行
3. 能够记录执行日志便于排查问题
4. 方案要简单可靠，易于维护

提示：Rocky Linux作为RHEL的替代发行版，其系统管理与RHEL/CentOS基本一致。理解这一点有助于我们在其他类似系统上迁移配置。

1.2 方案选型考量

在Linux系统中，实现开机自启动主要有以下几种方式：

1. systemd服务单元：现代Linux发行版的标准方式
2. rc.local：传统的启动脚本方式
3. cron @reboot：通过cron定时任务实现
4. init.d脚本：传统的SysV init方式

经过评估，我重点考虑了前两种方案。systemd是当前的标准方案，功能强大但配置相对复杂；rc.local虽然"古老"但简单直接，特别适合单一脚本的启动需求。

2. systemd方案实践与问题排查

2.1 systemd服务单元创建

首先尝试了systemd方案，创建了服务单元文件/etc/systemd/system/keepalived-web.service：

bash复制[Unit]
Description=Keepalived Web Service
After=network.target

[Service]
Type=oneshot
ExecStart=/opt/paraview/esc/bin/keepalived_web.sh start
RemainAfterExit=yes
User=root

[Install]
WantedBy=multi-user.target

关键参数解析：

• Type=oneshot：适用于执行一次性任务而非常驻服务
• RemainAfterExit=yes：即使命令执行完毕仍标记服务为active
• After=network.target：确保网络就绪后再执行脚本

2.2 systemd方案实施步骤

1. 创建服务文件后，需要重新加载systemd配置：

bash复制sudo systemctl daemon-reload

2. 启用服务开机自启动：

bash复制sudo systemctl enable keepalived-web

3. 手动启动服务测试：

bash复制sudo systemctl start keepalived-web

4. 检查服务状态：

bash复制sudo systemctl status keepalived-web

2.3 遇到的问题与排查

在实际操作中，遇到了几个典型问题：

1. 启动顺序问题：脚本依赖的其他服务可能还未完全就绪
2. 权限问题：虽然指定了User=root，但某些环境变量可能不同
3. 日志记录不足：难以追踪脚本执行过程中的具体问题

尝试过的解决方案包括：

• 调整After依赖项，增加network-online.target等
• 明确设置Environment参数
• 在脚本中添加详细的日志记录

经过多次调试，虽然服务能够运行，但始终存在一些不稳定因素。考虑到这是一个相对简单的启动需求，最终决定转向更传统的rc.local方案。

3. rc.local方案完整实现

3.1 rc.local方案的优势

选择rc.local方案主要基于以下考虑：

1. 简单性：只需在单一文件中添加命令
2. 可靠性：经过长期验证的传统方案
3. 低维护：不需要处理复杂的依赖关系
4. 通用性：几乎所有Linux发行版都支持

注意：虽然rc.local在现代systemd系统中是通过服务实现的（rc-local.service），但其使用方式与传统一致，保持了良好的兼容性。

3.2 详细配置步骤

3.2.1 编辑rc.local文件

bash复制sudo vi /etc/rc.d/rc.local

文件内容示例：

bash复制#!/bin/bash
# THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES
#
# It is highly advisable to create own systemd services or udev rules
# to run scripts during boot instead of using this file.
#
# In contrast to previous versions due to parallel execution during boot
# this script will NOT be run after all other services.
#
# Please note that you must run 'chmod +x /etc/rc.d/rc.local' to ensure
# that this script will be executed during boot.

touch /var/lock/subsys/local

# ============================================
# 启动 keepalived_web 服务
# ============================================
sudo /opt/paraview/esc/bin/keepalived_web.sh start >> /var/log/rc.local.log 2>&1

exit 0

关键点说明：

• >> /var/log/rc.local.log 2>&1：将标准输出和错误都重定向到日志文件
• exit 0：必须保留，表示脚本成功结束

3.2.2 设置执行权限

bash复制sudo chmod +x /etc/rc.d/rc.local

3.2.3 启用rc-local服务（如有必要）

在某些系统上，可能需要手动启用rc-local服务：

bash复制sudo systemctl enable rc-local
sudo systemctl start rc-local

3.3 验证与测试

1. 检查文件权限：

bash复制ls -l /etc/rc.d/rc.local
# 应有类似输出：-rwxr-xr-x. 1 root root 535 Jun 10 15:30 /etc/rc.d/rc.local

2. 手动测试执行：

bash复制sudo /etc/rc.d/rc.local

3. 检查日志输出：

bash复制tail -f /var/log/rc.local.log

4. 检查服务状态：

bash复制/opt/paraview/esc/bin/keepalived_web.sh status

5. 最终重启验证：

bash复制sudo reboot

4. 方案对比与经验总结

4.1 systemd与rc.local方案对比

4.2 操作经验与注意事项

1. 日志记录至关重要：

   • 无论是哪种方案，都要确保有足够的日志记录
   • 建议在脚本内部也添加日志功能，而不仅依赖外部重定向

2. 权限问题排查：

   • 确保脚本本身有执行权限（chmod +x）
   • 在rc.local中使用sudo可能并非必要，因为rc.local通常以root身份运行

3. 启动顺序考量：

   • 如果脚本依赖网络或其他服务，可在rc.local中添加简单检查：

     bash复制while ! ping -c 1 example.com &>/dev/null; do sleep 1; done
     

4. 备选方案考虑：

   • 对于需要延迟启动的场景，可以考虑使用cron的@reboot功能
   • 对于复杂的服务管理，仍建议使用systemd

5. 系统更新影响：

   • rc.local文件通常不会被系统更新修改，但最好定期检查
   • systemd服务文件也应纳入配置管理

5. 扩展知识与进阶技巧

5.1 systemd方案的优化方向

虽然本文最终选择了rc.local方案，但对于需要更复杂控制的场景，systemd仍有其优势。以下是几个优化方向：

1. 服务依赖精确控制：

   ini复制After=network-online.target
   Wants=network-online.target
   

2. 环境变量设置：

   ini复制Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
   

3. 资源限制：

   ini复制LimitNOFILE=65536
   LimitMEMLOCK=infinity
   

4. 重启策略：

   ini复制Restart=on-failure
   RestartSec=5s
   

5.2 rc.local的高级用法

1. 多命令执行与错误处理：

   bash复制/path/to/script1 || echo "script1 failed" >> /var/log/rc.local.log
   /path/to/script2 && echo "script2 succeeded" >> /var/log/rc.local.log
   

2. 条件执行：

   bash复制if [ -f /some/file ]; then
       /path/to/script
   fi
   

3. 启动延迟：

   bash复制sleep 10
   /path/to/script
   

5.3 其他替代方案简介

1. cron @reboot：

   bash复制crontab -e
   @reboot /path/to/script
   

2. systemd临时文件：

   bash复制sudo systemd-tmpfiles --create /etc/tmpfiles.d/myscript.conf
   

3. 用户级systemd服务：

   bash复制systemctl --user enable myservice
   

在实际工作中，选择哪种方案取决于具体需求、系统环境以及维护团队的熟悉程度。对于简单的启动需求，rc.local提供了快速可靠的解决方案；而对于复杂的服务管理，systemd则展现出其强大而灵活的特性。