CentOS7 启动脚本作用

在企业级服务器上，系统的每一次开机都相当于一次“交接仪式”，而启动脚本则是那位负责递交钥匙的管理员，它决定哪些服务先行、哪些任务随后执行，直接影响业务的可用性与恢复时长。

系统启动阶段概览

CentOS 7 采用 systemd 取代了传统的 SysVinit，启动过程被划分为 initrd、kernel、systemd 初始目标（如 graphical.target、multi-user.target）以及各个 service 单元的并行激活。每个目标下的依赖关系由 .service、.target、.socket 等文件在 /etc/systemd/system 与 /usr/lib/systemd/system 中声明。

rc.local 在 CentOS 7 的定位

虽然 systemd 已经提供了更细粒度的管理手段，/etc/rc.d/rc.local 仍被保留为兼容层。它在 multi-user.target 完全激活之后以单线程方式执行，仅在文件拥有可执行权限（chmod +x /etc/rc.d/rc.local）时才会被调用。实际场景中，运维人员常把一次性初始化脚本、临时调试命令塞进这里，以免在系统正式上线前编写完整的 unit 文件。

常见的启动脚本类型

• /etc/rc.d/rc.local：传统兼容入口，适合快速实验。
• .service 单元：推荐方式，可声明 After=、Requires= 等依赖，支持自动重启与日志收集。
• .timer 单元：若任务只需在系统启动后延迟执行，使用 timer 更加轻量。
• udev 规则：硬件层面的触发脚本，常用于磁盘挂载后立即执行检查。

实践：编写可靠的自定义服务

下面给出一个最小化的 myapp.service 示例，演示如何把 “开机创建 ~/test.txt” 这件事从 rc.local 移植到 systemd：

[Unit]
Description=Create test file at first boot
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'if [ ! -f /home/%u/test.txt ]; then touch /home/%u/test.txt; fi'
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

将文件保存至 /etc/systemd/system/myapp.service，随后执行 systemctl enable myapp.service 与 systemctl start myapp.service 即可。此方式的优势在于：系统会在网络等关键服务就绪后再运行，若脚本执行失败，systemd 会自动记录日志并提供重试策略，远比 rc.local 的盲目并行更可靠。

从根本上说，启动脚本的“作用”不只是“让命令跑起来”，而是通过依赖图、并行调度以及统一的日志体系，为整套业务提供可预测、可审计的启动路径。把握了这一点，运维人员便能在几行配置里把“开机即服务”做得既安全又优雅——