Linux-systemctl
- [Linux 的 systemctl:系统服务与资源管理核心工具](#Linux 的 systemctl:系统服务与资源管理核心工具)
-
- [一、核心定位传统的 `sysvinit` 存在启动慢(串行启动服务)、依赖管理复杂、无统一管理接口等问题。而 `systemd` 作为新一代系统初始化框架,通过 `systemctl` 实现:](#一、核心定位传统的
sysvinit存在启动慢(串行启动服务)、依赖管理复杂、无统一管理接口等问题。而systemd作为新一代系统初始化框架,通过systemctl实现:) - [二、systemctl 的核心作用](#二、systemctl 的核心作用)
-
- [1. 服务管理(最常用)](#1. 服务管理(最常用))
-
- [状态输出解读(`systemctl status sshd`)](#状态输出解读(
systemctl status sshd))
- [状态输出解读(`systemctl status sshd`)](#状态输出解读(
- [2. 系统状态管理(系统级操作)](#2. 系统状态管理(系统级操作))
- [3. 挂载点管理(替代 `mount`/`umount` 持久化配置)](#3. 挂载点管理(替代
mount/umount持久化配置)) - [4. 定时器管理(替代 `cron` 部分场景)](#4. 定时器管理(替代
cron部分场景)) - [5. 其他核心功能](#5. 其他核心功能)
-
- [(1)查看系统资源单元(所有被 systemd 管理的资源)](#(1)查看系统资源单元(所有被 systemd 管理的资源))
- [(2)日志查看(集成 `journald` 日志系统)](#(2)日志查看(集成
journald日志系统)) - (3)依赖关系查看
- [(4)系统运行级别管理(替代传统 `runlevel`)](#(4)系统运行级别管理(替代传统
runlevel))
- [三、systemctl 与传统工具的对比(运维迁移参考)](#三、systemctl 与传统工具的对比(运维迁移参考))
- 四、核心优势总结
- 五、常见使用误区
- [一、核心定位传统的 `sysvinit` 存在启动慢(串行启动服务)、依赖管理复杂、无统一管理接口等问题。而 `systemd` 作为新一代系统初始化框架,通过 `systemctl` 实现:](#一、核心定位传统的
Linux 的 systemctl:系统服务与资源管理核心工具
systemctl 是 Linux 系统中 systemd 系统初始化管理器 的命令行接口(CLI),自 CentOS 7、Ubuntu 15.04 起成为主流 Linux 发行版的默认系统管理工具,替代了传统的 sysvinit(service、chkconfig 命令)和 upstart。其核心作用是 统一管理系统服务、挂载点、定时器、设备、快照等系统资源,提供高效的并行启动、依赖管理、状态监控等功能。
一、核心定位传统的 sysvinit 存在启动慢(串行启动服务)、依赖管理复杂、无统一管理接口等问题。而 systemd 作为新一代系统初始化框架,通过 systemctl 实现:
- 并行启动服务:大幅提升系统启动速度;
- 统一管理接口:所有系统资源(服务、挂载、定时器等)用同一命令管理;
- 精确的依赖控制:自动处理服务启动顺序(如先启动数据库再启动 Web 服务);
- 实时状态监控:查看服务运行状态、日志、资源占用;
- 开机自启配置:简化服务开机启动的启用/禁用;
- 系统状态管理:关机、重启、挂起等系统级操作。
二、systemctl 的核心作用
1. 服务管理(最常用)
管理系统服务(如 sshd、nginx、firewalld 等),是运维日常操作的核心。
| 操作 | 命令示例 | 说明 |
|---|---|---|
| 启动服务(临时) | sudo systemctl start sshd |
立即启动服务,重启系统后失效 |
| 停止服务(临时) | sudo systemctl stop sshd |
立即停止服务,重启系统后失效 |
| 重启服务 | sudo systemctl restart sshd |
停止后重新启动(适合修改配置后) |
| 重新加载配置(不重启) | sudo systemctl reload sshd |
不停止服务,仅加载新配置(支持的服务才有效,如 nginx、sshd) |
| 查看服务状态 | sudo systemctl status sshd |
显示服务运行状态、PID、日志片段、是否开机自启(核心命令) |
| 启用开机自启 | sudo systemctl enable sshd |
永久设置服务开机启动(重启后生效) |
| 禁用开机自启 | sudo systemctl disable sshd |
永久禁用服务开机启动(重启后生效) |
| 查看是否开机自启 | sudo systemctl is-enabled sshd |
输出 enabled(启用)/disabled(禁用)/masked(屏蔽) |
| 屏蔽服务(禁止启动) | sudo systemctl mask sshd |
彻底禁止服务启动(即使其他服务依赖或手动执行 start 也无效) |
| 解除屏蔽 | sudo systemctl unmask sshd |
恢复被屏蔽的服务 |
状态输出解读(systemctl status sshd)
● sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled) # 已加载、开机自启
Active: active (running) since 一 2024-05-20 10:00:00 CST; 2h 30min ago # 正在运行(核心状态)
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 1234 (sshd) # 主进程ID
Tasks: 1 (limit: 4915)
Memory: 1.2M
CGroup: /system.slice/sshd.service
└─1234 /usr/sbin/sshd -D
5月 20 10:00:00 localhost systemd[1]: Started OpenSSH server daemon.
- Active 状态核心值 :
active (running):正常运行;inactive (dead):未运行;active (exited):一次性服务(如systemd-tmpfiles-setup)执行完毕且成功;failed:启动失败(需查看日志排查)。
2. 系统状态管理(系统级操作)
替代传统的 shutdown、reboot、halt 等命令,统一管理系统运行状态。
| 操作 | 命令示例 | 说明 |
|---|---|---|
| 重启系统 | sudo systemctl reboot / sudo reboot |
立即重启(等价于传统 reboot) |
| 关机(立即) | sudo systemctl poweroff / sudo poweroff |
立即关机(等价于传统 poweroff) |
| 关机(延迟10分钟) | sudo systemctl poweroff -i 10 |
10分钟后关机,可通过 sudo systemctl cancel 取消 |
| 挂起系统(休眠) | sudo systemctl suspend |
保存当前状态到内存,恢复时快速唤醒(需硬件支持) |
| 休眠到磁盘 | sudo systemctl hibernate |
保存当前状态到磁盘,断电后不丢失(恢复速度比挂起慢) |
| 救援模式(单用户) | sudo systemctl rescue |
进入单用户模式(用于系统故障排查,如密码重置、配置修复) |
| 紧急模式 | sudo systemctl emergency |
更精简的单用户模式(仅挂载 / 为只读,需手动挂载其他分区) |
3. 挂载点管理(替代 mount/umount 持久化配置)
systemd 支持通过「挂载单元(.mount 文件)」管理文件系统挂载,比传统 fstab 更灵活,支持依赖管理和自动修复。
| 操作 | 命令示例 | 说明 |
|---|---|---|
| 查看所有挂载单元 | systemctl list-units --type=mount |
显示所有已加载的挂载点(包括 /、/home 等) |
| 挂载指定单元 | sudo systemctl mount /mnt/data |
挂载 /etc/systemd/system/mnt-data.mount 定义的挂载点(需先创建单元文件) |
| 卸载挂载单元 | sudo systemctl umount /mnt/data |
卸载挂载点,等价于 umount /mnt/data |
| 启用开机自动挂载 | sudo systemctl enable mnt-data.mount |
永久设置挂载点开机自动挂载 |
| 查看挂载单元状态 | systemctl status mnt-data.mount |
检查挂载是否正常、挂载点路径、设备等 |
4. 定时器管理(替代 cron 部分场景)
systemd 的「定时器单元(.timer 文件)」可实现定时任务,支持精确到毫秒、依赖管理、日志集成,比 cron 更灵活(适合需要依赖服务的定时任务)。
| 操作 | 命令示例 | 说明 |
|---|---|---|
| 查看所有定时器 | systemctl list-timers |
显示所有已启用的定时器(下次执行时间、上次执行时间) |
| 启动定时器 | sudo systemctl start backup.timer |
启动定时任务(对应的服务为 backup.service) |
| 启用开机自启定时器 | sudo systemctl enable backup.timer |
永久设置定时器开机自启 |
| 查看定时器状态 | systemctl status backup.timer |
检查定时器是否运行、下次执行时间等 |
5. 其他核心功能
(1)查看系统资源单元(所有被 systemd 管理的资源)
bash
# 查看所有已加载的单元(服务、挂载、定时器等)
systemctl list-units
# 查看所有已安装的单元(包括未加载的)
systemctl list-unit-files
# 按类型过滤(如仅查看服务单元)
systemctl list-units --type=service
(2)日志查看(集成 journald 日志系统)
systemctl 与 journalctl 联动,可直接查看服务或系统日志(替代传统 /var/log/messages):
bash
# 查看 sshd 服务的实时日志
sudo journalctl -u sshd -f
# 查看系统所有日志(按时间倒序)
sudo journalctl -r
# 查看今天的系统日志
sudo journalctl --since today
(3)依赖关系查看
查看服务之间的依赖(如 nginx 依赖 network.target 网络服务):
bash
systemctl list-dependencies nginx.service
(4)系统运行级别管理(替代传统 runlevel)
systemd 用「目标单元(.target)」替代传统运行级别(如 runlevel 3 对应 multi-user.target):
bash
# 查看当前运行级别
systemctl get-default
# 设置默认运行级别为多用户模式(无图形界面)
sudo systemctl set-default multi-user.target
# 设置默认运行级别为图形界面模式
sudo systemctl set-default graphical.target
三、systemctl 与传统工具的对比(运维迁移参考)
| 操作需求 | 传统命令(sysvinit) | systemctl 命令 |
|---|---|---|
| 启动服务 | service sshd start |
systemctl start sshd |
| 停止服务 | service sshd stop |
systemctl stop sshd |
| 查看服务状态 | service sshd status |
systemctl status sshd |
| 启用开机自启 | chkconfig sshd on |
systemctl enable sshd |
| 禁用开机自启 | chkconfig sshd off |
systemctl disable sshd |
| 重启系统 | reboot |
systemctl reboot |
| 关机 | shutdown -h now |
systemctl poweroff |
| 查看运行级别 | runlevel |
systemctl get-default |
四、核心优势总结
- 统一接口:所有系统资源(服务、挂载、定时器等)用同一命令管理,无需记忆多个工具;
- 高效并行 :服务并行启动,系统启动速度比传统
sysvinit快 50%+; - 强大依赖管理:自动处理服务启动顺序,避免因依赖未就绪导致的启动失败;
- 完整日志集成 :与
journald联动,日志查看更便捷(支持实时监控、按服务过滤); - 灵活扩展:支持自定义单元文件(服务、定时器等),满足复杂业务需求;
- 跨发行版兼容:主流 Linux 发行版(CentOS、Ubuntu、Debian、Fedora)均默认支持。
五、常见使用误区
- 混淆
start与enable:start是临时启动服务,enable是设置开机自启,需同时执行(如sudo systemctl enable --now sshd一键启用并启动); - 修改配置后未重载 :部分服务(如
sshd、nginx)修改配置后,需执行reload而非restart(避免服务中断); - 屏蔽服务后无法启动 :
mask会禁止服务启动,需用unmask解除后再start; - 忽略依赖失败 :若服务启动失败,可通过
systemctl status 服务名查看日志,大概率是依赖服务未启动(如数据库服务未启动导致 Web 服务启动失败)。