Linux systemd闲谈杂话（第一篇：概述）

systemd 是 Linux 系统中广泛使用的初始化系统（init system）和服务管理器，旨在替代传统的 SysV init 和 Upstart。

它通过并行化启动、依赖管理、精细的服务控制等特性，显著提升了系统启动速度和服务管理效率，尤其适合对可靠性和实时性要求较高的嵌入式场景。

一、systemd 的核心设计目标

1. 更快启动：并行启动无依赖的服务，替代 SysV init 的串行执行模式。

2. 服务生命周期管理：支持服务的启动、停止、重启、重载，并监控服务状态（崩溃自动重启）。

3. 依赖解析：明确服务间的依赖关系（如网络服务启动前确保网络就绪）。

4. 统一管理接口：通过 systemctl命令集中管理系统服务、挂载点、设备、套接字等。

5. 日志与诊断：集成 journald日志系统，提供结构化日志查询。

二、systemd 核心概念与组件

1. Unit（单元）

systemd 以 Unit 文件​ 为核心，每个 Unit 对应系统中的一个资源或服务，类型包括：

• Service Unit（.service）：管理后台服务（如 nginx.service、自定义应用服务）。

• Target Unit（.target）：逻辑分组单元（类似 SysV init 的运行级别），用于协调一组 Unit 的启动（如 multi-user.target对应多用户模式）。

• Mount Unit（.mount）：管理文件系统挂载点（替代 /etc/fstab的部分功能）。

• Socket Unit（.socket）：管理套接字，触发对应服务启动（类似 xinetd 的按需启动）。

• Device Unit（.device）：管理硬件设备（基于 udev 规则自动生成）。

• Path Unit（.path）：监控文件/目录变化，触发服务（如日志轮转监控）。

Unit 文件位置：

• 系统级：/usr/lib/systemd/system/（发行版预定义）

• 用户级：~/.config/systemd/user/或 /etc/systemd/user/

• 临时覆盖：/etc/systemd/system/<unit>.d/override.conf（通过 systemctl edit修改）

2. Service Unit 关键配置（.service文件）

以自定义应用 my_monitor_app.service为例，核心字段：

[Unit]
Description=My Embedded Monitor Application  # 描述
After=network.target syslog.target           # 依赖：网络和日志系统就绪后启动
Requires=network.target                      # 强依赖（网络失败则本服务不启动）[Service]
Type=simple                                  # 进程类型（simple：前台运行；forking：后台守护进程）
ExecStart=/opt/myapp/bin/monitor_app         # 启动命令
ExecStop=/bin/kill -TERM $MAINPID            # 停止命令（可选）
Restart=on-failure                           # 故障时自动重启（策略：always/on-success/on-failure）
User=root                                    # 运行用户（嵌入式可能用普通用户降低权限）
Group=root                                   # 运行组
Environment="DEBUG=1"                        # 环境变量
LimitNOFILE=65535                            # 资源限制（文件描述符数量）[Install]
WantedBy=multi-user.target                   # 安装到 multi-user.target 的依赖链

Type 类型说明：

• simple：默认，服务主进程前台运行（systemd 认为启动即完成）。

• forking：服务通过 fork()后台运行（需指定 PIDFile）。

• oneshot：一次性任务（如初始化脚本，需 RemainAfterExit=yes保持激活状态）。

3. Target Unit（运行级别）

Target 是一组 Unit 的逻辑集合，通过名称映射传统 SysV init 的运行级别：

Target 名称	类似 SysV 运行级别	描述
rescue.target	单用户模式	仅 root 可登录，用于修复
multi-user.target	多用户（无图形）	基础服务器模式
graphical.target	图形界面	包含图形服务（如 Xorg）
shutdown.target	关机	触发所有服务停止

依赖关系：

graphical.target通常依赖 multi-user.target，并通过 Wants关联图形服务（如 gdm.service）。

4. 依赖管理关键字

Unit 文件中通过以下字段定义依赖：

• After/Before：定义启动/停止顺序（不强制依赖，仅顺序）。

• Requires：强依赖（依赖的 Unit 失败则本服务失败）。

• Wants：弱依赖（依赖的 Unit 失败不影响本服务）。

• BindsTo：严格绑定（依赖的 Unit 退出则本服务退出）。

三、systemd 核心命令（systemctl）

1. 服务管理

# 启动/停止/重启服务
systemctl start/stop/restart my_monitor_app.service# 查看服务状态（含日志片段）
systemctl status my_monitor_app.service# 启用/禁用开机自启（创建/删除到 target 的软链接）
systemctl enable/disable my_monitor_app.service# 查看服务是否启用
systemctl is-enabled my_monitor_app.service

2. Target 管理

# 切换到多用户模式（需 root）
systemctl isolate multi-user.target# 查看当前激活的 target
systemctl get-default# 设置默认启动 target（如图形界面）
systemctl set-default graphical.target

3. 日志查看（依赖 journald）

# 查看指定服务的日志（-u 指定 unit，-f 跟踪最新日志）
journalctl -u my_monitor_app.service -f# 查看所有错误日志
journalctl -p err# 按时间过滤（最近 10 分钟）
journalctl --since "10 minutes ago"

四、嵌入式场景下的 systemd 优化

1. 轻量级配置

• 裁剪 Unit 文件：仅保留必要的服务和依赖，避免冗余。

• 禁用不需要的服务：

  systemctl disable bluetooth.service avahi-daemon.service  # 关闭蓝牙、Avahi 等非必要服务

• 使用 static服务：对无需手动启动的服务（仅被其他服务依赖），设置为 Type=oneshot并禁用 AllowIsolate=yes，减少内存占用。

2. 加速启动

• 并行启动：systemd 默认并行启动无依赖的 .service，可通过 systemd-analyze分析启动时间：

  systemd-analyze time          # 查看总启动时间（用户空间/内核）
  systemd-analyze blame         # 列出各服务启动耗时（优化高耗时服务）
  systemd-analyze critical-chain my_monitor_app.service  # 查看关键路径

• 减少同步操作：避免服务启动时等待磁盘 I/O（如将临时文件挂载到 tmpfs）。

3. 只读文件系统适配

嵌入式设备常使用只读根文件系统，需处理可写路径（如日志、配置）：

• 临时文件：通过 tmpfiles.d配置（/etc/tmpfiles.d/下的 .conf文件），定义 tmpfs挂载：

  # /etc/tmpfiles.d/myapp.conf
  D /var/log/myapp 0755 root root -  # 临时目录，重启清空

• 可写分区：使用 overlayfs将只读根文件系统与 lowerdir（只读）、upperdir（可写）叠加，systemd 自动管理挂载。

4. 资源限制与安全

• 限制进程资源：通过 systemd-run或 Unit 文件的 [Service]字段：

  [Service]
  MemoryLimit=512M        # 内存限制
  CPUQuota=80%            # CPU 占用限制

• 沙盒化：使用 ProtectSystem=strict（只读 /usr、/boot、/etc）、PrivateTmp=yes（隔离 /tmp）增强安全性。

五、实战：为 ZynqMP 解码器设计服务

假设需要开发一个视频解码服务 video_decoder.service，要求：

• 依赖网络和存储设备就绪后启动。

• 崩溃后自动重启（最多 3 次）。

• 日志保存到 /var/log/video_decoder.log。

步骤 1：编写 .service文件​

/etc/systemd/system/video_decoder.service：

[Unit]
Description=Video Decoder Service for ZynqMP Monitor
After=network.target local-fs.target  # 存储设备（local-fs）就绪后启动
Requires=network.target[Service]
Type=simple
ExecStart=/opt/video_decoder/bin/decoder --input /mnt/sdcard/input.h264
ExecStop=/bin/kill -TERM $MAINPID
Restart=on-failure
RestartSec=5s                          # 崩溃后等待 5 秒重启
StartLimitInterval=10s                 # 10 秒内最多重启 3 次（结合 StartLimitBurst）
StartLimitBurst=3
User=appuser                           # 普通用户运行，降低权限
Group=appgroup
StandardOutput=file:/var/log/video_decoder.log  # 输出重定向到日志文件
StandardError=inherit                  # 错误输出继承标准输出[Install]
WantedBy=multi-user.target

步骤 2：启用并启动服务

# 重载 systemd 配置（新增/修改 unit 后必须执行）
systemctl daemon-reload# 启用开机自启
systemctl enable video_decoder.service# 启动服务并查看状态
systemctl start video_decoder.service
systemctl status video_decoder.service

步骤 3：调试与优化​

若服务启动失败，通过 journalctl查看日志：

journalctl -u video_decoder.service -e  # 查看错误详情
systemd-analyze blame | grep decoder   # 检查是否因该服务导致启动延迟

六、总结

systemd 是嵌入式 Linux 开发中不可或缺的工具，尤其在 ZynqMP 等高性能 SoC 方案中，其并行启动、服务管理、依赖解析特性可显著提升系统可靠性和开发效率。关键要点：

• 掌握 .service文件编写，明确定义依赖和资源限制。

• 利用 systemctl和 journalctl高效管理服务与排查问题。

• 结合嵌入式场景优化（裁剪、只读适配、资源限制）。

惠州西湖