systemd 的 *ctl

前两篇分别把 systemd 管了什么（unit） 和 整机姿态（target / 旧 runlevel） 说清楚了。日常敲键盘时，你碰到的却往往是另一串名字：systemctl、journalctl、loginctl、hostnamectl……它们看起来像平行世界里的不同工具，其实同属一套家族。

这篇只做一件事：讲清 关系——谁是 PID 1、谁是配套守护进程、谁是薄客户端遥控器；再给每条常用命令几条「你会真敲」的子命令，深度案例链到站内旧文，不把 man 页抄一遍。

读前可先备着的入口

• 系列：unit 类型与后缀 · runlevel 与 target
• 总览：systemd(1)
• 文末有完整参考资料与站内实践互链

一、先记住一张家族图

粗分三层就够用：

flowchart TB
  pid1[systemd_PID1]
  bus[DBus]

  pid1 --> bus

  subgraph daemons [配套守护进程]
    journald[systemd-journald]
    logind[systemd-logind]
    hostnamed[systemd-hostnamed]
    timedated[systemd-timedated]
    localed[systemd-localed]
    resolved[systemd-resolved]
    networkd[systemd-networkd]
  end

  bus --> daemons

  subgraph ctls [用户侧ctl客户端]
    systemctlCmd[systemctl]
    journalctlCmd[journalctl]
    loginctlCmd[loginctl]
    hostnamectlCmd[hostnamectl]
    timedatectlCmd[timedatectl]
    localectlCmd[localectl]
    resolvectlCmd[resolvectl]
    networkctlCmd[networkctl]
  end

  systemctlCmd --> pid1
  journalctlCmd --> journald
  loginctlCmd --> logind
  hostnamectlCmd --> hostnamed
  timedatectlCmd --> timedated
  localectlCmd --> localed
  resolvectlCmd --> resolved
  networkctlCmd --> networkd

四句口诀：

1. PID 1（systemd）：编排 unit / target——开机后用户态总管家。
2. 配套守护进程：各自管一块「主机策略」（日志、会话、主机名、时间、locale、DNS、网络……），多经 D-Bus 暴露接口。
3. *ctl：薄客户端——不是第二套 init，而是问对应守护进程（或 PID 1）的遥控器。
4. 用户实例：systemctl --user 管的是「当前用户的 systemd」；要让它在无人登录时仍活着，往往还要碰 loginctl enable-linger。

对照表（命令 → 对话对象 → 管什么）：

所以：背「systemd 有哪些命令」不如背「这块事归哪个守护进程，遥控器叫什么」。

二、systemctl：轴心遥控器

systemctl 是你和 unit 依赖图 打交道的主入口。前两篇里出现的 status、get-default、isolate，都落在这里。

1. 日常最常用的几下

systemctl status sshd.service
systemctl cat sshd.service          # 实际加载了哪份文件（含 drop-in）
sudo systemctl edit sshd.service    # 在 /etc 写覆盖，别直接改 /usr

sudo systemctl start sshd.service
sudo systemctl stop sshd.service
sudo systemctl enable --now sshd.service   # 开机启用并立刻启动
sudo systemctl disable --now sshd.service

systemctl list-units --type=service --state=running
systemctl get-default                 # 见第二篇：default.target

改完 unit 文件或 drop-in 之后：

sudo systemctl daemon-reload

2. 系统实例 vs 用户实例

不加参数时，systemctl 默认管 系统级 unit（/etc/systemd/system/、/usr/lib/systemd/system/ 那一套）。

加 --user 则对话 当前用户的 systemd 实例（配置常在 ~/.config/systemd/user/）。家用 rootless 容器、个人开发依赖服务，多半走这条线：

systemctl --user daemon-reload
systemctl --user enable --now something.service
systemctl --user status something.service

站内实践：Gitea + Podman + systemd 里整条链路是 loginctl enable-linger + systemctl --user；Podman + Quadlet 笔记 同属「用户级 unit」世界。

3. 依赖怎么扫一眼（点到为止）

unit 文件里常见三类关系（细节以 systemd.unit(5) 为准）：

排障时用：

systemctl list-dependencies sshd.service
systemctl show sshd.service -p After -p Wants -p WantedBy

第二篇的 multi-user.target / graphical.target，正是大量服务通过 WantedBy= 挂进去的「整机姿态」。

三、journalctl：问 journald 要日志

服务状态用 systemctl status；要翻历史、按启动次过滤、跟日志，用 journalctl——它读的是 systemd-journald 维护的日志库，不是「另一个 init」。

journalctl -u sshd.service          # 某 unit
journalctl -b                       # 本次启动以来
journalctl -b -1                    # 上一次启动
journalctl -f -u sshd.service       # 跟踪（类似 tail -f）
journalctl --since "1 hour ago"

排硬件休眠、内核与用户态交接这类问题时，往往先 journalctl -b 把时间线铺开。站内例子：Fedora s2idle / 休眠排查——结论就是从 journal 里读出来的。

systemctl status 末尾常附带一小段近期日志；不够时再切到 journalctl，两条命令是接力，不是重复造轮子。

四、loginctl：会话、seat 与 linger

systemd-logind 管登录会话、seat（键盘鼠标显示这一套）、用户能否在注销后仍保留用户级 systemd。遥控器是 loginctl。

loginctl list-sessions
loginctl user-status
loginctl show-user "$USER"

和容器 / rootless 最相关的一句：

sudo loginctl enable-linger rootless    # 允许该用户在无人登录时仍跑 --user 服务
sudo loginctl disable-linger rootless

没有 linger 时：用户一注销，用户实例和挂在上面的 Podman 服务可能一起收掉——这正是第一篇「用户级 unit」和第二篇「别拿 target 硬套容器生命周期」之外的那条线。

站内：Gitea 部署、私有 registry 都显式用了 enable-linger。

五、主机身份与环境：hostnamectl / timedatectl / localectl

这三家各自背后是 hostnamed / timedated / localed，模式相同：改「这台机器是谁、几点、说哪种语言/键盘」，不经 systemctl start 去「启动一个叫 hostname 的服务」那种直觉。

hostnamectl

hostnamectl status
sudo hostnamectl set-hostname wj

Static / Pretty / Transient 三种主机名、以及「别把 FQDN 随手塞进短名格子」——站内有完整排查故事：hostname 与 FQDN。这里只记：设主机名走 hostnamed 的遥控器，不是随便 echo 进某个文件就完事（发行版仍可能有多处配置互相影响）。

timedatectl

timedatectl status
timedatectl list-timezones | head
sudo timedatectl set-timezone Asia/Shanghai
timedatectl show-timesync     # 若启用了 systemd-timesyncd 一类同步

localectl

localectl status
localectl list-locales | head
sudo localectl set-locale LANG=en_US.UTF-8
sudo localectl set-keymap us

六、网络支线：resolvectl / networkctl（可选）

第一篇已划界：桌面/笔记本很常见的是 NetworkManager；systemd-networkd 更常见于服务器或明确选用 networkd 的环境。因此这两条遥控器 不是人人天天用，但同属家族地图：

resolvectl status
resolvectl query example.com

networkctl status
networkctl list

若本机主配网是 NetworkManager，排网问题优先走 nmcli / NM 文档；此时 networkctl 可能几乎无事可做——家族里有这个成员，不代表你这台机器启用了它。

七、其余点名：知道存在即可

下面这些仍是 systemd 生态里的常见工具，日常不必先背熟，需要时再 man：

systemd-analyze blame
systemd-analyze critical-chain
busctl list | head
coredumpctl list

systemd-run 和第一篇的 .scope / .slice 对得上：临时进程组也是 unit 模型的一部分，只是不一定落成长期文件。

八、怎么记：一张图，两条线

横向（家族）：PID 1 编排 unit；各守护进程管主机策略；*ctl 是遥控器。

纵向（你每天会碰到的两条操作线）：

系统服务线：
  systemctl ……          → PID 1 的系统实例
  journalctl -u ……      → 同一服务的日志

用户 / 容器线：
  loginctl enable-linger
  systemctl --user ……   → 用户实例上的 unit（含 Quadlet 生成物）

整机姿态（get-default / target）仍用 systemctl，那是第二篇；unit 类型与后缀是第一篇。本篇补的是：命令名背后站着谁。

若还要往下写，比较自然的切口是：把 After / Wants / Requires / BindsTo 做成依赖专篇，或单独把 Quadlet 从「生成器」讲到生产维护——都不必再重复这张 *ctl 地图。

参考资料

官方手册

• systemctl(1)
• journalctl(1)
• loginctl(1)
• hostnamectl(1) / timedatectl(1) / localectl(1)
• resolvectl(1) / networkctl(1)
• systemd-journald(8) / systemd-logind(8)
• systemd.unit(5) — After / Wants / WantedBy
• systemd-analyze(1) / systemd-run(1)

本机：man systemctl、man journalctl、man loginctl 等。

发行版与背景阅读

• Fedora Quick Doc：Understanding and administering systemd
• Arch Wiki：systemd — 命令与排障例子多（路径习惯对照 Fedora）
• RHEL 9：Managing services with systemd

站内相关

• systemd 管了什么：unit 类型与文件后缀
• 从 runlevel 到 target
• hostname 与 FQDN
• Fedora s2idle / 休眠排查
• Gitea + Podman + systemd
• docker registry 与 linger
• podman generate systemd / Quadlet 笔记