AI 创作声明：本系列文章由笔者借助 ChatGPT, Kimi K2, 豆包和 Cursor 等 AI 工具创作，有很大篇幅的内容完全由 AI 在我的指导下生成。如有错误，还请指正。

前言

系统关机看似简单，但背后涉及了繁杂的资源清理和状态管理过程。当你点击关机按钮，系统却卡在那里不动，或者出现各种奇怪的错误信息时，理解关机流程和故障排查方法就显得尤为重要。

除了关机，Linux 还提供了休眠和挂起两种重要的电源管理功能，它们可以让系统快速进入低功耗状态，同时保持工作状态，是日常使用中非常实用的功能。

作为这个系列的最后一篇文章，本文将探讨系统关机的完整流程，以及休眠和挂起功能的配置与故障排查，从优雅关闭到强制关机，从服务停止到资源清理，从电源管理到状态恢复，全面了解系统的电源管理机制。

系统关机流程

1.1 关机流程概览

systemd 管理的关机过程分为四个主要阶段，每个阶段都有明确的目标和顺序，确保数据完整性和系统稳定性。

关机阶段：

1. 用户会话清理阶段（约 1-5 秒）：

   • 通知所有用户会话即将关机
   • 优雅关闭用户应用程序
   • 回收用户设备权限

2. 系统服务停止阶段（约 2-10 秒）：

   • 按依赖关系逆向停止系统服务
   • 卸载文件系统（除根文件系统外）
   • 网络服务断开连接

3. 内核资源释放阶段（约 1-3 秒）：

   • 同步所有文件系统到磁盘
   • 卸载根文件系统为只读
   • 终止所有剩余进程

4. 硬件关机阶段（约 1-2 秒）：

   • 通过 ACPI 发送关机信号
   • 固件接管系统控制权
   • 所有硬件设备断电

1.2 用户会话清理

当用户发起关机时，systemd 首先处理用户会话的清理工作，确保用户数据得到妥善保存。

会话清理流程：

# systemd 发送关机信号
systemctl start shutdown.target

# 用户会话收到终止信号
loginctl terminate-session <session_id>

# 用户服务停止
systemctl --user stop graphical-session.target

关键操作：

• 会话通知：通过 D-Bus 向桌面环境发送关机信号
• 应用关闭：等待应用保存未保存的数据
• 权限回收：logind 回收分配给用户的设备访问权限
• 服务停止：用户 systemd 实例停止所有用户服务

监控用户会话清理：

# 查看会话状态变化
journalctl -b | grep -E "(session|Session)"

# 用户服务停止日志
journalctl --user -b | grep -E "(Stopping|Stopped)"

# 设备权限回收
journalctl -u systemd-logind -b | grep -i "device"

1.3 系统服务停止

用户会话清理完成后，systemd 开始按依赖关系的逆向顺序停止系统服务。

服务停止顺序：

• 图形服务：合成器、显示管理器
• 网络服务：网络管理器、DNS 解析器
• 存储服务：磁盘管理、LVM
• 基础服务：日志、设备管理

关键服务处理：

# 查看关机时的服务停止顺序
systemd-analyze critical-chain shutdown.target

# 监控服务停止状态
watch -n 1 'systemctl list-units --state=deactivating'

# 检查服务停止日志
journalctl -b -1 | grep -E "(Stopping|Stopped)" | tail -20

文件系统卸载：

# 查看挂载点卸载情况
mount | grep -v "on / type"

# 文件系统同步状态
sync
echo 3 > /proc/sys/vm/drop_caches

# 检查卸载错误
journalctl -b -1 | grep -i "unmount\|busy"

1.4 内核资源释放

当所有用户空间服务停止后，systemd 执行最终的系统清理：

文件系统操作：

• 调用 sync() 同步所有已挂载文件系统的数据到磁盘
• 按照逆向挂载顺序卸载所有挂载点
• 卸载外接硬盘分区等外部存储设备

进程管理：

• 向所有剩余进程发送 SIGTERM，给它们最后清理机会
• 等待超时后，对顽固进程发送 SIGKILL 强制终止
• 清理僵尸进程和孤儿进程

Watchdog 监控：

• systemd 的看门狗机制监控服务关闭进度
• 如果服务停止超过 TimeoutStopSec，强制终止服务
• 防止系统在关机过程中无限挂起

资源清理：

• GPU 驱动重置显卡状态，释放 VRAM
• 网络设备完全断电
• 音频设备硬件重置

1.5 硬件关机

当所有用户空间和内核资源处理完毕后，系统进入硬件关机：

ACPI 操作：

• systemd 通过 ACPI 向固件发出关机指令
• 进入 ACPI S5 状态，告诉固件关闭电源

固件接管：

• BIOS/UEFI 接管系统控制权
• 执行电源关断，所有设备（CPU、内存、GPU、外部设备）断电
• 固件执行最后的清理工作

强制关机保护：

• 如果系统未能正常关机，硬件看门狗可能强制切断电源
• 用户长按电源键也会触发强制关机

此时机器完全断电，关机过程结束。下次开机将重新开始完整的启动周期。

1.6 关机故障排查

常见关机问题与优化：

1. 服务停止超时：

# 查看超时服务
journalctl -b -1 | grep -i "timeout"

# 检查特定服务配置
systemctl cat <service> | grep Timeout

服务停止超时优化：

TimeoutStopSec 参数控制服务停止的最大等待时间，默认值为 90 秒。systemd 在停止服务时会等待服务自行退出，超时后强制终止。对于快速停止的服务，可以设置较短的超时时间（如 10-30 秒）， 配置示例：TimeoutStopSec=30s 设置 30 秒超时。

服务停止优化包括：服务应该正确处理 SIGTERM 信号，完成必要的清理工作；避免在停止过程中进行耗时的操作；确保及时释放文件句柄、网络连接等资源。

2. 文件系统卸载失败：

# 查找占用文件系统的进程
lsof | grep <mountpoint>

# 检查文件系统状态
fsck -n /dev/<device>

文件系统卸载优化：

进程占用检查使用 lsof 命令查找仍在使用文件系统的进程。常见原因是应用程序未正确关闭文件句柄，或进程仍在运行。解决方案是强制终止占用进程，或等待进程自然结束。

文件系统状态检查包括：使用 fsck -n 进行只读检查，不修复文件系统；检查文件系统是否正确挂载，是否有错误标记；定期进行文件系统检查，及时发现和修复问题。

3. 设备繁忙：

# 检查设备占用
lsof | grep /dev/<device>

# 查看块设备状态
lsblk -f

设备占用优化：

设备占用分析检查哪些进程仍在使用设备文件。常见设备包括 USB 设备、外部存储、网络设备等。解决方案是确保应用程序正确关闭设备，或强制卸载设备。

块设备状态检查包括：使用 lsblk 查看设备挂载状态和文件系统类型；检查设备是否处于忙碌状态； 在关机前确保所有外部设备已安全移除。

强制关机处理与优化：

当正常关机失败时，可以使用以下方法：

# 安全强制关机
systemctl poweroff -f

# 紧急关机（立即执行）
systemctl poweroff -ff

# 内核强制重启
echo b > /proc/sysrq-trigger

# 内核强制关机
echo o > /proc/sysrq-trigger

强制关机方法：

systemctl poweroff -f 强制关机，跳过某些检查和服务停止。强制终止所有进程，直接进入关机流程，可能导致数据丢失，应谨慎使用，适用于系统响应缓慢但仍有基本功能时。

systemctl poweroff -ff 紧急关机，立即执行，不等待任何操作完成。立即终止所有进程，强制关机，高数据丢失风险，仅在紧急情况下使用，适用于系统完全无响应，需要立即关机。

echo b > /proc/sysrq-trigger 内核级别的强制重启。直接调用内核重启功能，绕过用户空间，即使系统完全无响应也能执行，适用于系统完全卡死，无法响应用户命令。

echo o > /proc/sysrq-trigger 内核级别的强制关机。直接调用内核关机功能，立即断电，最高数据丢失风险，适用于极端紧急情况，需要立即断电。

关机优化最佳实践：

预防措施：定期检查服务配置，确保服务能正常停止；监控文件系统状态，及时处理问题；避免在关机前进行大量 I/O 操作。

优雅关机：优先使用正常的关机命令；给系统足够时间完成清理工作；避免频繁使用强制关机。

故障预防：定期更新系统和驱动；监控系统资源使用情况；及时处理系统警告和错误。

系统休眠与挂起

除了关机，Linux 还提供了两种重要的电源管理功能：休眠（Hibernate）和挂起 （Suspend）。这两种功能可以让系统快速进入低功耗状态，同时保持工作状态，是日常使用中非常实用的功能。

3.1 休眠（Hibernate）功能

休眠是将系统内存中的所有数据保存到磁盘（通常是交换分区或交换文件），然后完全关闭电源。当系统从休眠中恢复时，会从磁盘读取保存的数据，恢复到休眠前的状态。

休眠的工作原理：

1. 内存数据保存：将 RAM 中的所有数据写入到交换分区或专门的休眠文件
2. 系统状态保存：保存 CPU 状态、设备状态、网络连接等
3. 完全断电：系统完全关闭，所有硬件断电
4. 快速恢复：开机时直接从磁盘恢复内存状态，跳过正常启动过程

休眠配置：

# 检查当前休眠配置
cat /sys/power/state
cat /sys/power/disk

# 检查交换分区大小（需要足够容纳内存数据）
swapon --show
free -h

# 检查休眠文件（如果使用文件而非交换分区）
ls -lh /swapfile

启用休眠功能：

# 方法一：使用交换分区
# 1. 确保有足够大的交换分区（建议为内存大小的 1.5-2 倍）
sudo swapon --show

# 2. 获取交换分区的 UUID
sudo blkid | grep swap

# 3. 更新 GRUB 配置
sudo nano /etc/default/grub
# 添加：GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=your-swap-uuid"

# 4. 更新 GRUB 配置
sudo update-grub

# 5. 重新生成 initramfs
sudo update-initramfs -u

# 方法二：使用交换文件
# 1. 创建交换文件（大小建议为内存的 1.5-2 倍）
sudo fallocate -l 8G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# 2. 永久挂载交换文件
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# 3. 配置休眠到交换文件
echo 'RESUME=UUID=$(findmnt -no UUID -T /swapfile)' | sudo tee /etc/initramfs-tools/conf.d/resume
sudo update-initramfs -u

休眠故障排查：

# 检查休眠支持
cat /sys/power/state | grep disk

# 检查休眠目标
cat /sys/power/disk

# 测试休眠功能
sudo systemctl hibernate

# 查看休眠日志
journalctl -b | grep -i hibernate
dmesg | grep -i hibernate

# 检查交换空间使用情况
swapon --show
free -h

常见休眠问题：

1. 交换空间不足：

   • 问题：交换分区或文件太小，无法容纳内存数据
   • 解决：增加交换空间大小，建议为内存的 1.5-2 倍

2. 休眠文件损坏：

   • 问题：休眠文件损坏导致恢复失败
   • 解决：删除损坏的休眠文件，重新创建

3. 硬件不支持：

   • 问题：某些硬件不支持休眠功能
   • 解决：检查 BIOS/UEFI 设置，更新固件

3.2 挂起（Suspend）功能

挂起是将系统进入低功耗状态，保持内存供电，CPU 和大部分硬件断电。系统可以快速恢复到挂起前的状态，但需要持续供电。

挂起的工作原理：

1. 内存保持供电：RAM 继续供电，保持数据不丢失
2. CPU 进入睡眠状态：CPU 进入深度睡眠，功耗极低
3. 外设断电：硬盘、USB 设备、网络设备等断电
4. 快速唤醒：通过键盘、鼠标、网络唤醒等快速恢复

挂起类型：

• S1（Power On Suspend）：CPU 停止执行，但保持供电
• S2（CPU Off）：CPU 断电，但保持缓存
• S3（Suspend to RAM）：CPU 和缓存断电，仅内存供电
• S4（Suspend to Disk）：等同于休眠

挂起配置：

# 检查支持的挂起状态
cat /sys/power/state

# 检查当前挂起模式
cat /sys/power/mem_sleep

# 设置挂起模式（deep 为 S3，s2idle 为 S2）
echo deep | sudo tee /sys/power/mem_sleep

# 永久设置挂起模式
echo 'mem_sleep_default=deep' | sudo tee -a /etc/default/grub
sudo update-grub

挂起故障排查：

# 测试挂起功能
sudo systemctl suspend

# 查看挂起日志
journalctl -b | grep -i suspend
dmesg | grep -i suspend

# 检查挂起相关服务
systemctl status systemd-suspend
systemctl status systemd-hibernate

# 检查挂起钩子脚本
ls -la /usr/lib/systemd/system-sleep/

常见挂起问题：

1. 挂起后无法唤醒：

   • 问题：系统挂起后无法通过键盘、鼠标唤醒
   • 解决：检查 BIOS 设置，启用 USB 唤醒功能

2. 挂起后系统重启：

   • 问题：挂起后系统自动重启而不是恢复
   • 解决：检查硬件兼容性，更新驱动

3. 挂起功耗过高：

   • 问题：挂起状态下功耗仍然很高
   • 解决：检查外设电源管理，禁用不必要的设备

3.3 电源管理模式对比

选择建议：

• 短时间离开（几分钟到几小时）：使用挂起
• 长时间离开（几小时到几天）：使用休眠
• 长期不使用（几天以上）：使用关机

混合使用策略：

# 设置自动挂起（当系统空闲时）
sudo systemctl enable systemd-suspend.timer

# 设置定时休眠（夜间自动休眠）
sudo systemctl edit systemd-hibernate.timer
# 添加：
[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

在实际使用中，大多数用户通过桌面环境的设置界面来配置电源管理功能。GNOME、KDE Plasma、XFCE 等桌面环境都提供了图形化的电源管理设置，可以方便地配置自动挂起和休眠时间。

对于使用 Wayland 合成器（如 Sway、Hyprland）的用户，通常使用专门的 idle 守护进程来管理电源状态。swayidle、hypridle 等工具可以配置系统在空闲时自动锁屏、关闭显示器或进入挂起状态。

电源管理优化：

# 检查电源管理配置
cat /sys/power/pm_async
cat /sys/power/pm_freeze_timeout

# 优化挂起延迟
echo 5000 | sudo tee /sys/power/pm_freeze_timeout

# 检查设备电源管理
ls /sys/bus/usb/devices/*/power/
cat /sys/bus/usb/devices/*/power/control

通过合理配置和使用休眠、挂起功能，可以显著提高 Linux 桌面系统的使用体验，既节省电力又保持工作状态的连续性。

实战案例：综合故障排查

在实际使用 Linux 桌面系统时，往往会遇到多层次、多组件交织的故障。通过系统化的排查方法，可以快速定位问题并制定解决方案。本章通过几个典型案例，讲解如何综合使用日志、调试工具和系统命令进行故障排查。

2.1 案例一：桌面环境无法启动

现象：用户登录后，屏幕闪烁后回到登录界面，桌面无法显示。

排查步骤：

1. 检查显示管理器状态：

systemctl status display-manager
journalctl -u display-manager -b

2. 确认用户会话：

loginctl list-sessions
loginctl show-session <session_id>

3. 检查合成器日志（Wayland 示例）：

journalctl --user -u sway -f
export WAYLAND_DEBUG=1

4. 检查 GPU 驱动状态：

lspci -k | grep -A 3 -i vga
dmesg | grep -i drm

常见原因：

• 驱动不匹配或未加载
• 合成器启动失败
• 用户环境变量设置错误

解决方法：

• 更新或切换 GPU 驱动
• 使用默认配置启动合成器
• 检查 $XDG_RUNTIME_DIR 和 $WAYLAND_DISPLAY 是否正确

2.2 案例二：应用程序崩溃或无响应

现象：某些应用程序启动后立即崩溃，或运行中无响应。

排查步骤：

1. 查看用户服务日志：

journalctl --user -b -u <application>.service

2. 启用应用调试信息：

export GDK_DEBUG=all    # GTK 应用
export QT_LOGGING_RULES="qt.qpa.*=true"  # Qt 应用
export WAYLAND_DEBUG=1

3. 分析核心转储：

coredumpctl list
coredumpctl info <pid>
coredumpctl debug <pid>

4. 检查依赖库版本：

ldd $(which <application>)

常见原因：

• 缺少或版本不匹配的库
• Wayland/Xwayland 支持不完整
• GPU 驱动异常

解决方法：

• 安装或升级依赖库
• 强制应用使用 X11 或 Wayland 后端
• 检查驱动更新或使用回滚版本

2.3 案例三：系统关机或重启异常

现象：系统关机卡住，服务停止超时，最终需要强制关机。

排查步骤：

1. 查看关机日志：

journalctl -b -1 -e
systemd-analyze blame shutdown.target

2. 检查服务停止状态：

systemctl list-units --state=deactivating
journalctl -b -1 | grep -E "(Stopping|Stopped)"

3. 文件系统状态：

mount | grep -v "on / type"
lsof | grep <mountpoint>

4. 硬件设备状态：

lsblk -f
dmesg | grep -i "error\|fail\|timeout"

常见原因：

• 某些服务或进程未能及时停止
• 文件系统被占用或损坏
• 设备驱动异常导致无法卸载

解决方法：

• 强制停止顽固服务：

systemctl stop <service> -i

• 检查并修复文件系统：

fsck -n /dev/<device>

• 临时使用强制关机：

systemctl poweroff -ff

2.4 案例四：网络异常导致应用无法访问

现象：应用启动正常，但无法连接网络资源。

排查步骤：

1. 检查网络接口和状态：

ip addr
ip route
nmcli device status

2. 测试 DNS 和连通性：

ping 8.8.8.8
dig www.example.com

3. 查看网络服务日志：

journalctl -u NetworkManager -b

4. 检查防火墙和权限：

sudo iptables -L -v -n
sudo nft list ruleset

常见原因：

• DHCP 或静态 IP 配置错误
• DNS 配置异常
• 防火墙阻塞访问

解决方法：

• 修复网络配置
• 检查防火墙规则
• 重启网络服务

2.5 综合排查方法

面对复杂问题，单靠经验可能难以定位故障，推荐遵循以下方法：

1. 日志为先：系统日志、用户服务日志、应用日志是最直接的线索
2. 逐层排查：从硬件 → 驱动 → 系统服务 → 用户会话 → 应用
3. 最小复现：关闭非必要服务和应用，简化环境重现问题
4. 工具辅助：journalctl、strace、coredumpctl、lsof、perf 等
5. 文档与社区：查阅官方文档和社区经验，快速定位常见故障

通过上述方法，可以系统化地分析并解决大多数 Linux 桌面问题，提高系统稳定性和用户体验。

总结

至此，我们已经完成了《Linux 桌面系统故障排查指南》系列的全部六篇文章。通过这个系列，我们全面了解了 Linux 桌面系统的各个组件，从启动安全到网络配置，从多媒体输入到会话管理，从系统服务到电源管理。

Linux 桌面系统虽然有时候会出各种奇怪的问题，但理解其工作原理后，大部分问题都能找到解决思路。关键是要有耐心，多实践，多总结。特别是在电源管理方面，合理使用关机、休眠和挂起功能，可以显著提高系统的使用体验和电力效率。

这个系列到这里就结束了，希望这些内容能帮助你在 Linux 桌面的道路上走得更顺畅一些。

🔗 相关资源

• 技术文档：systemd 官方文档、Wayland 协议规范
• 社区资源：Arch Wiki、Gentoo Wiki

AI 创作声明：本系列文章由笔者借助 ChatGPT, Kimi K2, 豆包和 Cursor 等 AI 工具创作，有很大篇幅的内容完全由 AI 在我的指导下生成。如有错误，还请指正。

概述

本文是《Linux 桌面系统故障排查指南》系列的第二篇，专注于 systemd 生态系统与服务管理。在上一篇中，我们了解了系统启动与安全框架，现在让我们深入探讨 systemd 核心功能以及 systemd 生态系统中的各个专门化组件。

⚙️ 本文主要介绍如下内容：

• systemd 核心功能：服务管理、依赖关系、并行启动、单元类型配置
• systemd 生态系统服务：systemd-journald、systemd-oomd、systemd-resolved、systemd-timesyncd、systemd-udevd 等
• 设备管理：udev 规则和设备权限分配、故障排查
• D-Bus 系统总线：进程间通信机制、权限管控、调试方法

1. systemd 核心功能

systemd 作为 PID 1，是现代 Linux 系统的初始化系统和服务管理器。它负责并行启动服务、维护依赖关系、管理 cgroups，并提供统一的系统管理接口。

1.1 systemd 概览与基本操作

systemd 作为现代 Linux 系统的初始化系统和服务管理器，主要专注于服务管理和系统控制。

核心功能：

• 服务管理：并行启动 units，维护依赖关系
• 资源控制：通过 cgroups 实现进程隔离和资源限制
• 系统状态管理：通过 target 管理不同的系统运行状态
• 单元生命周期管理：管理各种类型单元（service、mount、timer 等）的启动、停止和重启

常用命令：

# 系统状态查看
systemctl get-default                     # 默认 target
systemctl list-units --type=service       # 列出服务
systemctl status sshd.service             # 服务状态

# 性能分析
systemd-analyze blame                     # 启动耗时分析
systemd-analyze critical-chain            # 关键路径分析

# 服务管理
systemctl start/stop/restart service      # 服务控制
systemctl enable/disable service          # 开机自启控制
systemctl reload service                  # 重载配置

NixOS 特殊说明：在 NixOS 中，/etc/systemd/system 下的配置文件都是通过声明式参数生成的软链接，指向 /nix/store。修改配置应通过 NixOS 配置系统，而非直接编辑这些文件。NixOS 没有传统的 /usr 和 /lib 等 FHS 目录，所有软件包都存储在 /nix/store 中，通过/run/current-system/sw/ 等符号链接提供访问。

配置文件路径：

• /etc/systemd/system/：系统级服务配置
• /run/current-system/sw/lib/systemd/system/（NixOS）或 /usr/lib/systemd/system/（传统发行版）：软件包提供的默认配置
• /etc/systemd/user/：用户级服务配置

1.2 服务单元类型与配置

systemd 支持多种单元类型，每种类型都有其特定的用途和配置方式。

主要单元类型：

• service：服务单元，管理后台进程
• target：目标单元，用于系统状态管理
• mount：挂载单元，管理文件系统挂载
• timer：定时器单元，替代 cron 任务
• socket：套接字单元，按需启动服务

服务单元配置示例：

[Unit]
Description=My Custom Service
After=network.target
Wants=network.target

[Service]
Type=simple
ExecStart=/usr/bin/my-service
Restart=always
User=myuser
Group=mygroup

[Install]
WantedBy=multi-user.target

1.3 systemd 依赖关系与启动顺序

systemd 通过依赖关系管理服务的启动顺序，确保服务按正确的顺序启动。

依赖关系类型：

• Requires：强依赖，被依赖服务失败时，依赖服务也会失败
• Wants：弱依赖，被依赖服务失败时，依赖服务仍可启动
• After：启动顺序依赖，确保在指定服务之后启动
• Before：启动顺序依赖，确保在指定服务之前启动

示例配置：

[Unit]
Description=Web Server
After=network.target
Wants=network.target
Requires=nginx.service

[Service]
Type=forking
ExecStart=/usr/sbin/nginx
Restart=always

[Install]
WantedBy=multi-user.target

2. systemd 生态系统服务

除了基本的服务管理外，systemd 还提供了多个专门化的系统服务来支持现代 Linux 桌面的核心功能，包括日志管理、内存管理、DNS 解析和时间同步等。

本节内容仅介绍最核心的几个 systemd 服务。

systemd 全家桶，你值得拥有（

2.1 日志系统：systemd-journald

systemd-journald 是 systemd 内置的日志收集守护进程，统一处理内核、系统服务及应用的日志，是现代 Linux 系统日志管理的核心组件。

2.1.1 核心特性

2.1.2 日志的4个收集入口

journald 仅通过标准化入口收集日志，确保来源可追溯：

1. 内核日志：内核 printk() 输出 → /dev/kmsg → journald（会自动添加 _PID/_COMM 等字段）；
2. systemd 单元 stdout/stderr：单元进程输出自动捕获，会附加_SYSTEMD_UNIT=xxx.service 等 systemd 相关字段；
3. 本地 Socket：/run/systemd/journal/socket 等，接收 logger/systemd-cat 及旧 syslog 应用日志；
4. 显式 API：sd_journal_send()，仅需自定义复杂结构化日志时使用（譬如 Docker daemon）, 一般直接 print 即可。

2.1.3 日志优先级与核心配置

1. 日志优先级简述

日志按严重程度分 8 级（数字越小，级别越高），常用级别：

• err：错误（部分功能异常），级别 3
• warning：警告（潜在风险），级别 4
• info：信息（常规运行日志），级别 6
• debug：调试（开发细节），级别 7

可用于筛选关键日志。

2. journald 配置

主配置文件：/etc/systemd/journald.conf，支持通过 /etc/systemd/journald.conf.d/*.conf 覆盖配置，核心配置项如下：

生产配置示例：

# /etc/systemd/journald.conf.d/00-production.conf
[Journal]
Storage=persistent
SystemMaxUse=2G
MaxRetentionSec=3month
ForwardToSyslog=yes
Seal=yes

配置生效需重启服务：sudo systemctl restart systemd-journald

2.1.4 实验：用 logger 验证日志收集

下面演示如何使用 logger 将结构化日志直接写进 journal，并立即用 journalctl 检索。

首先写入日志：

logger --journald <<EOF
SYSLOG_IDENTIFIER=myapp
PRIORITY=3
MESSAGE=用户登录失败
USER_ID=alice
LOGIN_RESULT=fail
EOF

其中的 SYSLOG_IDENTIFIER, PRIORITY, MESSAGE 在 journald 中都有属性对应，而后两个USER_ID 与 LOGIN_RESULT 则属于自定义的日志标签。

然后查询日志：

# 2. 按标识符过滤
journalctl -t myapp
# 等价于
journalctl SYSLOG_IDENTIFIER=myapp

# 3. 按优先级+自定义字段精确定位
journalctl -p err LOGIN_RESULT=fail

2.1.5 旧日志系统与 /var/log/ 解析

旧日志系统：基于 syslog 的文本管理

在 systemd 普及前，Linux 依赖 syslog 协议+文本文件 管理日志，核心组件是rsyslog（syslog 主流实现，功能强于早期 syslogd）。

• 旧系统工作流：应用通过 syslog(3) 接口输出日志 → rsyslog 接收 → 按「设施+优先级」写入 /var/log/ 文本文件；
• 现代系统中的角色：rsyslog 不再是核心收集器，而是作为「兼容层」——接收 journald 转发的日志，生成传统文本文件（如 /var/log/auth.log），或转发到远程日志服务器（支持 TCP/TLS 加密）。

/var/log/ 常见文件及功能

现代系统中，这些文件由 rsyslog 生成（兼容旧习惯），不同发行版名称略有差异，但都为纯文本格式：

2.1.6 日志写入最佳实践

2.1.7 运维命令速查

# 一、日志查询（含优先级过滤）
# 实时跟踪服务日志（仅看 err 及以上级别）
journalctl -f -p err -u sshd.service
# 等价于
journalctl -f -p err _SYSTEMD_UNIT=sshd.service
# 按时间+优先级过滤（过去1小时 warning 及以上）
journalctl --since "1h ago" -p warning
# -p 的参数既可使用名称，也可使用对应的数字，warning 对应 4
journalctl --since "1h ago" -p 4
# 内核日志（本次启动的 err 日志）
journalctl -k -p err -b
# 按自定义字段过滤（USER_ID=1001 + 优先级 err）
journalctl USER_ID=1001 -p err
# 通过 Perl 格式的正则表达式搜索日志
journalctl --grep "Auth"

# 二、日志管理
# 查看 journal 占用空间
sudo journalctl --disk-usage
# 清理日志（保留最近2周/500M）
sudo journalctl --vacuum-time=2weeks
sudo journalctl --vacuum-size=500M
# 手动轮转日志
sudo journalctl --rotate

# 三、旧日志文件操作
# 实时查看认证日志（Ubuntu）
tail -f /var/log/auth.log
# 实时查看认证日志（CentOS）
tail -f /var/log/secure

# 四、日志防篡改验证
sudo journalctl --setup-keys > /etc/journal-seal-key
sudo chmod 600 /etc/journal-seal-key
sudo journalctl --verify --verify-key=$(cat /etc/journal-seal-key)

2.2 内存管理：systemd-oomd

systemd-oomd 是 systemd 提供的内存不足（OOM）守护进程，用于在系统内存紧张时主动终止进程， 防止系统完全卡死。听起来有点"残忍"，不过总比系统彻底死机要好。

工作原理：

• 内存监控：实时监控系统内存使用情况和内存压力
• 智能选择：基于 cgroup 层次结构和内存使用量选择要终止的进程
• 用户空间保护：优先终止用户空间进程，保护系统关键服务
• 渐进式处理：逐步释放内存，避免过度 kill 进程

配置示例：

# NixOS 配置
systemd.oomd.enable = true;

systemd.oomd.extraConfig = ''
  [OOM]
  DefaultMemoryPressureLimitSec=20s
  DefaultMemoryPressureLimit=60%
'';

配置文件路径：/etc/systemd/oomd.conf

监控与调试：

# 查看 oomd 状态
systemctl status systemd-oomd

# 内存压力信息
cat /proc/pressure/memory

# 查看 oomd 日志
journalctl -u systemd-oomd -f

# 内存使用统计
systemctl status user@$(id -u).service

2.3 DNS 解析：systemd-resolved

systemd-resolved 提供统一的 DNS 解析服务，支持 DNSSEC 验证、DNS over TLS 等现代 DNS 特性。名字是长了点，不过功能倒是挺全面的，基本上把 DNS 解析这件事包圆了。

主要功能：

• 统一接口：为系统提供单一的 DNS 解析入口
• 本地缓存：缓存 DNS 查询结果，提高解析速度
• DNSSEC 支持：验证 DNS 响应的真实性
• 隐私保护：支持 DNS over TLS(DoT), 但截止目前（2025 年）尚未支持 DNS over HTTPS(DoH).

配置方法：

# 启用 systemd-resolved
services.resolved.enable = true;

# 配置 DNS 服务器
networking.nameservers = [
  "8.8.8.8" "1.1.1.1"                    # IPv4
  "2001:4860:4860::8888" "2606:4700:4700::1111"  # IPv6
];

# 高级配置
services.resolved.extraConfig = ''
  [Resolve]
  DNSSEC=yes
  DNSOverTLS=yes
  Cache=yes
'';

配置文件路径：/etc/systemd/resolved.conf

使用命令：

# DNS 状态查看
resolvectl status

# DNS 查询测试
resolvectl query example.com
resolvectl query -t AAAA ipv6.google.com

# 缓存管理
resolvectl flush-caches
resolvectl statistics

# DNS 服务器状态
resolvectl dns

2.4 时间同步：systemd-timesyncd

systemd-timesyncd 是轻量级 NTP 客户端，负责保持系统时间与网络时间服务器同步。功能简单直接，就是确保你的系统时间不会跑偏，避免出现"时间穿越"的尴尬情况。

功能特点：

• 轻量级设计：相比完整 NTP 服务占用更少资源
• 自动同步：定期与时间服务器同步
• SNTP 协议：使用简单网络时间协议
• systemd 集成：与 systemd 服务管理深度集成

NixOS 配置：

# 启用时间同步
services.timesyncd.enable = true;

# 配置 NTP 服务器
services.timesyncd.servers = [
  "pool.ntp.org"
  "time.google.com"
  "ntp.aliyun.com"
];

配置文件路径：/etc/systemd/timesyncd.conf

时间同步管理：

# 时间状态查看
timedatectl status
timedatectl timesync-status

# 手动控制
timedatectl set-ntp true   # 启用 NTP
timedatectl set-timezone Asia/Shanghai

# 查看同步日志
journalctl -u systemd-timesyncd -f

# 时间精度检查
chronyc tracking  # 如果安装了 chrony

3. 设备管理：udev 与 systemd-udevd

udev 是 Linux 用户空间的设备管理员，负责处理内核的设备事件，创建节点并设置权限。在现代 systemd 系统中，udev 功能由 systemd-udevd 守护进程实现，它是 systemd 生态系统的重要组成部分。

3.1 udev 与 systemd-udevd

3.1.1 udev 设备管理框架

udev 是 Linux 内核的用户空间设备管理框架，负责处理内核的设备事件并管理 /dev 目录下的设备节点。

udev 的核心功能：

• 动态设备管理：当硬件设备插入或移除时，自动创建设备节点
• 设备命名：提供一致的设备命名规则，如 /dev/disk/by-uuid/、/dev/input/by-id/
• 权限控制：根据设备类型和用户需求设置适当的设备权限
• 规则系统：通过规则文件实现复杂的设备处理逻辑

udev 的工作原理：

1. 内核检测到硬件变化，通过 netlink socket 发送 uevent 到用户空间
2. udev 守护进程接收 uevent，解析设备属性
3. 根据规则文件匹配设备，执行相应的动作（创建设备节点、设置权限等）

3.1.2 systemd-udevd 实现

在现代 systemd 系统中，udev 用户空间的功能由 systemd-udevd 守护进程实现，它是 systemd 生态系统的重要组成部分。

systemd-udevd 的优势：

• systemd 集成：作为 systemd 服务运行，享受 systemd 的服务管理、日志记录、依赖管理等功能
• 性能优化：相比传统的 udevd，systemd-udevd 在启动速度和资源使用上有所优化
• 统一管理：与 systemd 的其他组件（如 systemd-logind）深度集成，提供统一的设备权限管理

systemd-udevd 服务管理：

# 查看服务状态
systemctl status systemd-udevd

# 重启服务
sudo systemctl restart systemd-udevd

# 查看服务日志
journalctl -u systemd-udevd -f

3.1.3 工作流程

完整的设备管理流程如下：

1. 硬件检测：内核检测到硬件变化（插入、移除、状态改变）
2. 事件发送：内核通过 netlink socket 发送 uevent 到用户空间
3. 事件接收：systemd-udevd 接收 uevent，解析设备属性
4. 规则匹配：根据规则文件（/run/current-system/sw/lib/udev/rules.d/（NixOS）或/usr/lib/udev/rules.d/（传统发行版）、/etc/udev/rules.d/）匹配设备
5. 动作执行：执行匹配规则中定义的动作（RUN 脚本、设置 OWNER/GROUP/MODE、创建 symlink、设置权限）
6. systemd 集成：通知 systemd，可能触发 device units

3.1.4 配置示例

基本规则示例：

# /etc/udev/rules.d/90-mydevice.rules
SUBSYSTEM=="input", ATTRS{idVendor}=="abcd", ATTRS{idProduct}=="1234", MODE="660", GROUP="input", TAG+="uaccess"

规则说明：

• SUBSYSTEM=="input"：匹配输入设备子系统
• ATTRS{idVendor}=="abcd"：匹配厂商 ID
• ATTRS{idProduct}=="1234"：匹配产品 ID
• MODE="660"：设置设备权限为 660
• GROUP="input"：设置设备组为 input
• TAG+="uaccess"：添加 uaccess 标签，让 systemd-logind 接管设备权限

高级规则示例：

# /etc/udev/rules.d/99-custom-storage.rules
# 为特定 USB 存储设备创建符号链接
SUBSYSTEM=="block", ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678", SYMLINK+="myusb"

# 为特定网卡设置持久化名称
SUBSYSTEM=="net", ATTRS{address}=="aa:bb:cc:dd:ee:ff", NAME="eth0"

# 为特定设备运行自定义脚本
SUBSYSTEM=="usb", ATTRS{idVendor}=="abcd", RUN+="/usr/local/bin/my-device-handler.sh"

TAG+="uaccess" 是现代桌面用来让 systemd-logind 接管设备权限与 session ACL（由 logind 配置），确保只有当前活动会话能访问输入、音频、GPU 等设备。

3.2 设备权限与 ACL

现代 systemd + logind 使用 udev tag uaccess 或 seat 标签来由 logind 把设备 ACL 授予当前的登录 session。具体流程：

• systemd-udevd 创建 /dev/input/eventX 并打上 TAG+="uaccess".
• systemd-logind 对应的 PAM/session 系统会把该设备的 ACL 授予当前会话的用户，这样运行在会话内的 Wayland compositor 与其子进程可以访问设备。

检查设备权限分配：

# 查看某设备的 udev 属性
$ udevadm info -a -n /dev/input/event5

# 实时监控 udev 事件
$ sudo udevadm monitor --udev --property

# 查看 seat 状态与 ACL
$ loginctl seat-status seat0
# 或
$ loginctl show-session <id> -p Remote -p Display -p Name

3.3 故障排查

场景：插入外接键盘后，Wayland 会话收不到键盘事件（键盘无效）

排查步骤：

1. 检查 systemd-udevd 服务状态：

   bash

   systemctl status systemd-udevd

2. 在主机上用 udevadm monitor 插入键盘，观察是否有 udev 事件被触发：

   bash

   sudo udevadm monitor --udev

3. 检查 /dev/input/ 是否生成新节点：ls -l /dev/input/by-id。

4. 用 udevadm info -a -n /dev/input/eventX 查看该设备的属性，确认 TAG 是否包含uaccess 或 seat.

5. 使用 loginctl seat-status seat0 看设备是否分配给当前会话。若没有，可能是 PAM/session 未正确建立或 udev 规则没有打上 tag。

6. 检查 systemd-udevd 的日志：

   bash

   journalctl -b -u systemd-udevd
   journalctl -k | grep -i udev

7. 临时解决：用 chmod/chown 修改设备权限验证是否恢复（不建议长期采用）：

   bash

   sudo chown root:input /dev/input/eventX
   sudo chmod 660 /dev/input/eventX

8. 永久修复：在 /etc/udev/rules.d/ 中添加规则确保 TAG+="uaccess" 或正确的OWNER/GROUP。然后 udevadm control --reload-rules && sudo udevadm trigger。

注意：NixOS 下直接编辑 /etc/udev/rules.d 可能是临时的（Nix 管理的文件会被系统重建覆盖），正确做法是在 configuration.nix 中配置 services.udev.extraRules 或把规则放在environment.etc 并由 Nix 管理。

配置文件路径：

• /etc/udev/rules.d/：系统管理员自定义规则（优先级最高）
• /run/current-system/sw/lib/udev/rules.d/（NixOS）或 /usr/lib/udev/rules.d/（传统发行版）：软件包提供的默认规则

4. D-Bus 系统总线 - 应用间通信的主要通道

D-Bus 是 Linux 系统中主流的进程间通信（IPC）机制，旨在解决不同进程（尤其是桌面应用、系统服务）间的高效、安全通信问题，广泛用于 GNOME、KDE 等桌面环境及系统服务管理（如 systemd）。它本质是 “消息总线”，通过中心化的 “总线守护进程” 实现多进程间的消息路由。名字虽然有点奇怪， 功能倒是挺实在的。

4.1 D-Bus 项目背景

D-Bus 并非 systemd 社区的项目，而是 freedesktop.org 的独立项目。D-Bus 在 systemd 出现之前就已经存在，是 Linux 桌面环境标准化进程间通信的重要基础设施。

D-Bus 与 systemd 的关系：

• 独立项目：D-Bus 由 freedesktop.org 维护，有自己的发布周期和开发团队
• 深度集成：systemd 将 D-Bus 作为核心依赖，深度集成到其架构中
• 服务管理：systemd 负责启动和管理 D-Bus 守护进程（dbus-daemon）
• 统一接口：systemd 通过 D-Bus 提供统一的服务管理接口
  • systemd 本身就是一个 D-Bus 服务，我们在使用 systemctl 命令与 systemd 交互时，实际上就是 D-Bus 与 org.freedesktop.systemd1 通信。

4.2 关键概念

D-Bus 通过 「对象 - 接口」 模型（跟面向对象编程（OOP）中的概念有些类似）封装功能，以下结合systemd1 与 logind1 的真实定义，对应核心概念：

可使用 busctl list 查看系统中的所有 D-Bus 对象：

# 所有 system bus 对象
› busctl --system list --no-pager | grep org.
org.blueman.Mechanism                     - -               -                (activatable) -                         -       -
org.bluez                              1421 bluetoothd      root             :1.6          bluetooth.service         -       -
org.bluez.mesh                            - -               -                (activatable) -                         -       -
org.freedesktop.Avahi                  1420 avahi-daemon    avahi            :1.7          avahi-daemon.service      -       -
org.freedesktop.DBus                      1 systemd         root             -             init.scope                -       -
org.freedesktop.Flatpak.SystemHelper      - -               -                (activatable) -                         -       -
org.freedesktop.GeoClue2                  - -               -                (activatable) -                         -       -
org.freedesktop.PolicyKit1             2216 polkitd         polkituser       :1.22         polkit.service            -       -
org.freedesktop.RealtimeKit1           2539 rtkit-daemon    root             :1.41         rtkit-daemon.service      -       -
org.freedesktop.UDisks2                2492 udisksd         root             :1.31         udisks2.service           -       -
org.freedesktop.home1                     - -               -                (activatable) -                         -       -
org.freedesktop.hostname1                 - -               -                (activatable) -                         -       -
org.freedesktop.import1                   - -               -                (activatable) -                         -       -
org.freedesktop.locale1                   - -               -                (activatable) -                         -       -
org.freedesktop.login1                 1504 systemd-logind  root             :1.8          systemd-logind.service    -       -
org.freedesktop.machine1                  - -               -                (activatable) -                         -       -
org.freedesktop.network1               1292 systemd-network systemd-network  :1.3          systemd-networkd.service  -       -
org.freedesktop.oom1                    934 systemd-oomd    systemd-oom      :1.1          systemd-oomd.service      -       -
org.freedesktop.portable1                 - -               -                (activatable) -                         -       -
org.freedesktop.resolve1               1293 systemd-resolve systemd-resolve  :1.0          systemd-resolved.service  -       -
org.freedesktop.systemd1                  1 systemd         root             :1.4          init.scope                -       -
org.freedesktop.sysupdate1                - -               -                (activatable) -                         -       -
org.freedesktop.timedate1                 - -               -                (activatable) -                         -       -
org.freedesktop.timesync1              1148 systemd-timesyn systemd-timesync :1.2          systemd-timesyncd.service -       -
org.opensuse.CupsPkHelper.Mechanism       - -               -                (activatable) -                         -       -

# 所有 session bus 对象
› busctl --user list --no-pager | grep org.
...
org.fcitx.Fcitx-0                                                                 76699 fcitx5          ryan :1.284        user@1000.service -       -
org.fcitx.Fcitx5                                                                  76699 fcitx5          ryan :1.282        user@1000.service -       -
org.freedesktop.DBus                                                               2127 systemd         ryan -             user@1000.service -       -
org.freedesktop.FileManager1                                                          - -               -    (activatable) -                 -       -
org.freedesktop.Notifications                                                      3539 .mako-wrapped   ryan :1.81         user@1000.service -       -
org.freedesktop.ReserveDevice1.Audio0                                              2542 wireplumber     ryan :1.50         user@1000.service -       -
org.freedesktop.ReserveDevice1.Audio1                                              2542 wireplumber     ryan :1.50         user@1000.service -       -
org.freedesktop.ScreenSaver                                                        2192 niri            ryan :1.9          user@1000.service -       -
org.freedesktop.a11y.Manager                                                       2192 niri            ryan :1.13         user@1000.service -       -
org.freedesktop.impl.portal.PermissionStore                                        2410 .xdg-permission ryan :1.28         user@1000.service -       -
org.freedesktop.impl.portal.Secret                                                    - -               -    (activatable) -                 -       -
org.freedesktop.impl.portal.desktop.gnome                                             - -               -    (activatable) -                 -       -
org.freedesktop.impl.portal.desktop.gtk                                            2475 .xdg-desktop-po ryan :1.33         user@1000.service -       -
org.freedesktop.portal.Desktop                                                     2350 .xdg-desktop-po ryan :1.26         user@1000.service -       -
org.freedesktop.portal.Documents                                                   2428 .xdg-document-p ryan :1.30         user@1000.service -       -
org.freedesktop.portal.Fcitx                                                      76699 fcitx5          ryan :1.283        user@1000.service -       -
org.freedesktop.portal.Flatpak                                                        - -               -    (activatable) -                 -       -
org.freedesktop.portal.IBus                                                       76699 fcitx5          ryan :1.285        user@1000.service -       -
org.freedesktop.secrets                                                            2161 .gnome-keyring- ryan :1.55         session-1.scope   1       -
org.freedesktop.systemd1                                                           2127 systemd         ryan :1.1          user@1000.service -       -
...

4.3 系统总线与会话总线

4.4 D-Bus 的三类角色

1. 总线守护进程（dbus-daemon）

   架构的 「中枢」，每个总线对应一个守护进程，核心职责：

   • 管理进程的连接（如验证 普通用户 是否有权调用 logind1 的 PowerOff 方法）；

   • 路由消息（将客户端请求的 「启动 nginx 服务」 转发给 systemd1）；

   • 维护服务注册表（记录 org.freedesktop.login1 与 logind 进程的映射关系）。

2. 服务端（Service）

   提供功能的进程（如 systemd 进程、logind 进程），核心操作：

   • 向总线注册 「服务名」（systemd1 注册 org.freedesktop.systemd1，logind1 注册org.freedesktop.login1，均为唯一标识）；

   • 暴露 「对象」 和 「接口」（如 systemd1 暴露 /org/freedesktop/systemd1 对象与org.freedesktop.systemd1.Manager 接口），供客户端调用。

3. 客户端（Client）

   调用服务的进程（如 systemctl 命令、桌面电源菜单），核心操作：

   • 连接系统总线后，通过服务名（如 org.freedesktop.login1）找到 logind 服务；

   • 调用服务端暴露的方法（如通过 logind1 的 ListSessions 查询当前用户会话），或订阅信号（如监听 systemd1 的 UnitActiveChanged 单元状态变化）。

4.5 常见操作示例

下面我们通过一些命令来演示 D-Bus 总线的用途：

# 模拟 `systemctl status dbus` 的功能
busctl --system --json=pretty call \
  org.freedesktop.systemd1 \
  /org/freedesktop/systemd1/unit/dbus_2eservice \
  org.freedesktop.DBus.Properties GetAll s org.freedesktop.systemd1.Unit

# 模拟 `systemctl stop sshd`
sudo gdbus call --system \
  --dest org.freedesktop.systemd1 \
  --object-path /org/freedesktop/systemd1 \
  --method org.freedesktop.systemd1.Manager.StopUnit \
  "sshd.service" "replace"

# 模拟 `systemctl start sshd`
sudo gdbus call --system \
  --dest org.freedesktop.systemd1 \
  --object-path /org/freedesktop/systemd1 \
  --method org.freedesktop.systemd1.Manager.StartUnit \
  "sshd.service" "replace"

# 模拟 `notify-send "The Summary" "Here’s the body of the notification"`
nix shell nixpkgs#glib
gdbus call --session \
    --dest org.freedesktop.Notifications \
    --object-path /org/freedesktop/Notifications \
    --method org.freedesktop.Notifications.Notify \
    my_app_name \
    42 \
    gtk-dialog-info \
    "The Summary" \
    "Here’s the body of the notification" \
    [] \
    {} \
    5000

# 获取当前时区
busctl get-property org.freedesktop.timedate1 /org/freedesktop/timedate1 \
    org.freedesktop.timedate1 Timezone

# 查询主机名
busctl get-property org.freedesktop.hostname1 /org/freedesktop/hostname1 \
    org.freedesktop.hostname1 Hostname

4.6 调试与监控命令

# 看 systemctl 与 systemd 的完整交互（method-call + signal）
sudo busctl monitor --system | grep 'org.freedesktop.systemd1'
# 或者使用 --match 过滤，但这需要提前知道 interface 的全名
sudo busctl monitor --match='interface=org.freedesktop.systemd1.Manager'

# 跟 busctl monitor 功能几乎完全一致，也可通过 match rule 过滤
sudo dbus-monitor --system "interface='org.freedesktop.systemd1.Manager'"

# gdbus 只监听 signals，只能用来调试「服务有没有正确发出 signal」
sudo gdbus monitor --system -d org.freedesktop.systemd1.Manager

4.7 D-Bus 的权限管控

4.7.1 D-Bus 的原生权限管控机制

D-Bus 本身具备多层权限管控能力，从总线接入、消息路由到敏感操作授权，形成了系统级的基础安全保障，核心机制包括：

1. 总线配置文件（静态规则管控）

   通过 XML 配置文件定义细粒度访问规则，实现对 「谁能访问哪些服务 / 方法」 的静态限制。例如：

   • 系统总线的服务级规则（如 /etc/dbus-1/system.d/org.freedesktop.login1.conf）可限制普通用户调用 org.freedesktop.login1.Manager.PowerOff（关机方法）；

   • 全局规则（如 /etc/dbus-1/system.conf）可限定仅 root 或 dbus 组用户访问org.freedesktop.systemd1（systemd 服务）的核心接口。

     规则遵循 「deny 优先级高于 allow、服务级规则高于全局规则」 的逻辑，从总线层面直接拦截未授权请求。

2. PolicyKit（动态授权管控）

   针对静态规则无法覆盖的动态场景（如普通用户临时需要执行敏感操作），D-Bus 集成 PolicyKit（现称 polkit）实现动态授权。系统服务（如 logind1、systemd1）会在/run/current-system/sw/share/polkit-1/actions/（NixOS 中）或/run/current-system/sw/share/polkit-1/actions/（NixOS）或/usr/share/polkit-1/actions/（传统发行版中）定义 “可授权动作”，例如org.freedesktop.login1.power-off（对应 logind1 的关机方法）：

   • 普通用户调用时，会触发认证流程（如输入管理员密码），认证通过后临时获得授权；

   • 活跃控制台用户可直接授权，无需额外验证，兼顾安全性与易用性。

3. 连接层基础隔离

   D-Bus 总线套接字（如系统总线 /var/run/dbus/system_bus_socket）默认仅开放 root 和dbus 组用户的读写权限，普通进程需通过 dbus-daemon 认证后才能建立连接。同时，每个连接会被分配唯一 ID（如 :1.42），并与进程的 PID/UID/GID 绑定，防止身份伪造与未授权接入。

4.7.2 Flatpak 对 D-Bus 权限的细粒度管控

在现代 Linux 桌面中，若需将商业软件等非信任应用运行在沙箱中，同时保障 「必要 D-Bus 交互不中断、越权访问被阻断」，Flatpak 采用 「底层沙箱隔离 + 上层代理过滤」 的双层方案 —— 其中 bubblewrap 是 Flatpak 依赖的底层沙箱工具，负责环境隔离；xdg-dbus-proxy 是上层过滤组件，负责 D-Bus 细粒度管控，两者协同实现完整安全隔离：

4.7.2.1 底层基础隔离：bubblewrap 的 “socket 隐藏与代理挂载”

Flatpak 以 bubblewrap（简称 bwrap）为底层沙箱基础，利用其 bind mount 和user namespace 能力完成环境初始化，核心目标是切断沙箱应用与宿主 D-Bus 总线的直接联系：

• 隐藏宿主 socket：bubblewrap 会屏蔽宿主的 D-Bus 总线套接字（如不将/var/run/dbus/system_bus_socket 挂载进沙箱），避免应用绕过管控直接访问宿主总线；

• 挂载代理 socket：同时，bubblewrap 会将 xdg-dbus-proxy 在宿主侧预先创建的 私有代理 socket，通过 bind mount 挂载到沙箱内的默认 D-Bus socket 路径（如沙箱内的/var/run/dbus/system_bus_socket）。

  此时沙箱应用感知到的 「D-Bus 总线」，实际是 xdg-dbus-proxy 提供的代理接口，无法直接接触宿主真实总线。

4.7.2.2 上层规则过滤：xdg-dbus-proxy 的 “白名单校验”

xdg-dbus-proxy 作为 Flatpak 内置的 D-Bus 代理组件，会随沙箱应用启动，加载 Flatpak 根据应用权限声明自动生成的过滤规则（粒度远细于 D-Bus 原生静态配置），例如：

    --see=NAME                   Set 'see' policy for NAME
    --talk=NAME                  Set 'talk' policy for NAME
    --own=NAME                   Set 'own' policy for NAME
    --call=NAME=RULE             Set RULE for calls on NAME
    --broadcast=NAME=RULE        Set RULE for broadcasts from NAME

TODO

这些规则可精确到 「服务名 + 接口 + 方法 + 对象路径」，弥补 D-Bus 原生配置在沙箱场景下 「动态性不足、粒度较粗」 的局限。

4.7.2.3 消息流转：代理的 “校验 - 转发” 逻辑

沙箱应用无需修改代码，会默认连接沙箱内的 「代理 socket」，所有 D-Bus 消息（方法调用、信号订阅）均需经过 xdg-dbus-proxy 的校验：

• 若目标服务 / 方法在白名单内（如 org.freedesktop.portal.FileChooser.OpenFile），代理会将消息转发至宿主 D-Bus 总线，并把返回结果回传应用；

• 若目标不在白名单内（如 org.freedesktop.login1.Manager.PowerOff），代理直接返回AccessDenied 错误，不向宿主总线转发任何消息，彻底阻断越权访问。

总结

本文深入探讨了 systemd 核心功能及其生态系统，从服务管理到各个专门化组件：

1. systemd 核心功能：作为 PID 1 的服务管理器，专注于服务管理、依赖关系管理、资源控制和系统状态管理
2. systemd 生态系统服务：包括日志管理（journald）、内存管理（oomd）、DNS 解析 （resolved）、时间同步（timesyncd）、设备管理（udevd）等
3. 设备管理：udev 规则和设备权限分配，通过 systemd-udevd 确保硬件设备正确识别和访问
4. D-Bus 系统总线：进程间通信机制，支持系统服务和桌面应用的交互

虽然 systemd 的争议一直存在，但不可否认的是，它确实让系统管理变得更加统一和高效。掌握了这些组件的使用方法，你在面对各种系统问题时就不会那么手足无措了。

下一篇文章我们会聊聊桌面会话和图形渲染，看看用户登录后系统是如何把漂亮的桌面呈现给你的。