Linux服务管理为什么从service换成了systemctl?

一、SysV init的运行机制

CentOS 6及更早期的发行版采用System V init（SysV init）机制。该机制的核心设计是：每个服务对应一个独立的Shell脚本，集中存放于/etc/init.d/目录。管理员通过service命令或直接调用脚本来管理服务，例如service ssh start或/etc/init.d/ssh reload。

系统启动过程中，init进程按照预设的运行级别，依次执行对应的服务脚本。这一流程存在一项关键约束：脚本以串行方式执行，当前一个服务完成全部启动流程后，下一个服务才能开始加载。这意味着系统总启动时间约等于所有服务启动耗时之和。

在服务器负载较轻的早期环境中，一台主机仅承载三至五个服务，系统总启动时间尚在可接受范围内。随着业务规模扩大，单机服务数量增至数十个时，逐个等待的累积效应开始显现，开机耗时可能延长至数分钟。

除启动性能外，SysV init 还存在两项运维层面的不足：

• 依赖关系缺乏自动处理。若A 服务依赖网络就绪，B 服务依赖数据库实例启动，init 进程并不感知这些前置条件。脚本中通常插入 sleep 语句进行固定时长等待，服务的正常启动存在不确定性。

• 进程异常退出后无法自动恢复。当某个守护进程在运行中崩溃，init 进程不会尝试重新拉起。管理员需自行编写监控脚本，或在用户报告故障后才能发现异常。

上述缺陷在服务器数量增长后变得日益突出，推动社区探索更优的替代方案。

2010年前后，关于SysV init启动效率的讨论已在社区广泛展开。期间出现过Ubuntu曾采用的Upstart等过渡方案。最终成为主流发行版统一选择的，是由Red Hat工程师Lennart Poettering主导开发的systemd。

自CentOS 7、RHEL 7及Ubuntu 16.04起，systemd成为默认初始化系统。其设计目标并非修补SysV init的个别缺陷，而是构建一套完整的服务管理框架。systemd取代了传统的init进程，成为系统启动后的第一个进程（PID=1），所有其他进程均作为其子进程运行。按Linux命名惯例，后缀d表示守护进程，systemd即指负责守护整个系统的进程。

与SysV init 相比，systemd 引入了以下关键改进：

• 并行启动。SysV init 的串行等待是启动效率低下的主因。systemd 的策略是，服务之间若无显式依赖声明，则同时启动。这一调整将典型场景下的开机时间从分钟级降低至秒级。

• 依赖自动解析。服务配置中可通过Requires= 或 Wants= 声明依赖关系，systemd 据此自动判断依赖项的就绪状态。依赖未满足时挂起等待，满足后立即启动，无需再使用 sleep 进行固定延时。

• 异常退出自动重启。服务进程意外终止时，systemd 可按预置策略自动重启。该特性在 SysV init 环境下通常需借助 supervisord 等第三方工具实现，现仅需在配置中设定 Restart= 参数即可。

• 日志集中管理。SysV init 时代，各服务自行处理日志输出，部分写入 /var/log/ 下特定文件，部分仅输出至标准输出，排障时需逐一查找。systemd 通过 journald 统一收集所有服务的启动日志和运行时输出，使用 journalctl 即可完成集中检索。

• 统一管理接口。以往服务启停使用service，设置开机自启使用 chkconfig，两套工具语法各异。systemd 将全部管理操作整合至 systemctl 一个命令，降低了使用复杂度。

判断当前系统所使用的初始化系统，可依据发行版版本快速识别：CentOS 7 及以上、RHEL 7 及以上、Ubuntu 16.04 及以上均默认使用 systemd。仅仍在运行 CentOS 6 的旧环境使用 service 命令。

以firewalld.service 为例，日常运维中最常用的 systemctl 命令如下：

systemctl start firewalld.service       # 启动systemctl stop firewalld.service        # 停止systemctl restart firewalld.service     # 重启systemctl reload firewalld.service      # 重载配置，不中断服务systemctl enable firewalld.service      # 开机自启systemctl disable firewalld.service     # 禁止开机自启systemctl status firewalld.service      # 查看状态

需注意restart 与 reload 的区别：restart 执行先停止再启动的操作，服务在此期间发生中断。reload 则向服务进程发送信号，通知其重新读取配置文件，服务进程本身保持运行，不会中断现有连接。并非所有服务均支持 reload 操作；对于自行开发的应用，若未实现重载逻辑，执行 reload 可能触发完整重启或直接报错，具体行为取决于程序对信号的响应。

status命令的输出怎么看？

执行systemctl status 服务名时，应重点关注输出中的Active行，其状态显示为running、dead或failed。若状态为failed，systemd 通常会在下方附带最近的日志片段，据此可快速判断故障方向，常见原因包括端口占用、配置文件路径错误或依赖服务未就绪等。

服务起不来怎么排查？

当服务启动异常时，推荐的排查流程如下：

1.执行systemctl status 服务名，查看退出码及简要日志。

2.若信息不足，执行journalctl -xe -u 服务名 查看完整日志。其中 -x 选项会在日志中添加解释性说明，-e 选项可直接跳转至最近条目。

相比SysV init 时期需先确定日志文件位置及格式，再分散查阅的排查方式，现在通过统一的日志工具显著提升了排障效率。

从 SysV init 到 systemd，Linux 服务管理经历了从串行到并行、从分散到集中的演进历程。SysV init 退出历史舞台，并非由于其设计不佳，而是早期单机运行三五个服务的场景已不复存在。面对当今动辄数十上百个服务的部署密度，旧有机制在性能和可维护性上已难以满足需求。

日常运维中与 systemd 交互最为频繁的操作集中在服务启停、自启管理、状态查看及日志检索。掌握这些基础操作，可有效应对绝大多数管理场景，对于同时出现 service 与 systemctl 的历史教程也能具备清晰的辨识能力。

诚信  共赢  创新  发展