AI Agent Engineer

AI Agent Engineer

11 服务与日志

6 min read

11 服务与日志

学习目标

识别当前环境是否由 systemd 管理服务，区分“正在运行”和“开机启用”，使用只读命令查看 unit 配置、状态与 journal，并把日志证据与服务变更分开。

服务不是“后台有个进程”这么简单

服务管理器通常负责启动顺序、用户身份、环境、重启策略、资源限制、日志连接和依赖关系。nohup 或 tmux 只能维持会话中的进程，不能替代服务生命周期、健康检查和崩溃恢复。

Linux 常见 systemd，但并非必然：

  • 原生发行版常以 systemd 为 PID 1。
  • WSL 是否以 systemd 为 PID 1 取决于 WSL 版本、发行版与配置；必须读取当前环境证据。
  • 容器通常只运行一个应用进程，不以 systemd 为 PID 1。
  • macOS 使用 launchd，不适用 systemctl。

先识别环境：

ps -p 1 -o pid=,comm=,args=
command -v -- systemctl
systemctl --version

命令存在不等于 systemd 正在管理当前环境；systemctl 连接失败时应记录限制，不要安装或强行启动 systemd 来“修好练习”。

Unit、active 与 enabled

systemd 使用 unit 描述 service、socket、timer、mount 等对象。两个状态维度容易混淆：

  • active：该 unit 当前运行状态，例如 active、inactive、failed。
  • enabled：是否通过安装关系参与未来启动；enabled 不保证当前 active，active 也不保证 enabled。

查看运行中的服务：

systemctl list-units --type=service --state=running --no-pager

检查一个系统通常存在的 unit：

systemctl status --no-pager --lines=50 systemd-journald.service
systemctl is-active systemd-journald.service
systemctl is-enabled systemd-journald.service

is-active 与 is-enabled 通过退出码表达判断结果；“不是 active/enabled”不必然表示命令自身损坏。立即保存 $? 再运行其他命令。

配置证据：cat 与 show

systemctl cat systemd-journald.service
systemctl show \
  --property=Id,LoadState,ActiveState,SubState,MainPID,User,Group,ExecStart,Restart \
  systemd-journald.service
  • cat 展示 unit 文件和 drop-in，适合理解声明来源。
  • show 输出机器可读属性；未显式限制属性时内容很多，可能包含路径或环境信息。
  • status 面向人类，输出可能被截断，也可能夹带近期日志。

不同发行版的 unit 名称不同。真实 Agent 服务应先通过部署清单或 systemctl list-unit-files --type=service 确认名称，而不是猜 agent.service。

Journal：按时间和 unit 缩小范围

journalctl --unit=systemd-journald.service \
  --since '-10 min' \
  --lines=50 \
  --no-pager

常用只读过滤：

journalctl --priority=warning..alert --since today --no-pager
journalctl --boot=0 --lines=100 --no-pager
journalctl --disk-usage

注意：

  • 访问系统 journal 可能需要组权限或 sudo；没有授权就记录“权限不足”，不要默认提权。
  • 日志可能包含 token、用户输入、内部地址和请求体；先限定 unit、时间和行数，不粘贴原始全集。
  • --follow 会持续占用终端，按 Ctrl-c 停止。
  • 容器应用常把日志写到 stdout/stderr，由容器运行时收集；此时主机 journal、容器日志和应用文件是不同层。

用户服务与系统服务

普通用户也可能有 user unit：

systemctl --user list-units --type=service --state=running --no-pager

systemctl --user 连接用户级 manager，不等于系统级 service。排障报告要记录使用了哪一层、哪个用户和哪个 unit。

变更命令只作语法参考

systemctl start SERVICE
systemctl stop SERVICE
systemctl restart SERVICE
systemctl enable SERVICE
systemctl disable SERVICE
systemctl daemon-reload

这些命令会改变外部状态，可能中断流量或改变开机行为。本课程不把它们作为练习。真实操作前需要变更授权、依赖检查、健康检查、流量策略和回滚方案；修改 unit 后是否需要 daemon-reload 也应按实际变更决定。

只读排障流程

  1. 确认主机、用户、PID 1 和 systemd 可用性。
  2. 从部署清单确认 unit 名称。
  3. 保存 status、关键 show 属性和明确时间窗的 journal。
  4. 区分事实：unit 状态、MainPID、退出原因、日志时间。
  5. 再检查进程、端口与资源；不要看到一条错误日志就直接 restart。
  6. 把需要提权或变更的动作列为“待批准”，不在调查阶段执行。

动手练习

在自有且确实使用 systemd 的实验环境中，仅调查 systemd-journald.service：

unit='systemd-journald.service'
systemctl status --no-pager --lines=20 "$unit"
status_rc=$?
systemctl show --property=ActiveState,SubState,MainPID "$unit"
journalctl --unit="$unit" --since '-5 min' --lines=20 --no-pager
printf 'status_rc=%s\n' "$status_rc"

若环境不是 systemd，只写环境证据和“不适用”结论，不执行替代安装。报告必须区分 status 命令退出码、unit 当前状态和你尚未验证的应用健康。

掌握检查

  • 能解释 active 与 enabled 不同。
  • 能区分系统 unit、user unit 与容器应用进程。
  • 能限定 journal 的 unit、时间和行数，并说明秘密风险。
  • 能列出 start/restart 前必须获得的授权与回滚证据。

下一步：网络与端口。

参考资料

获取日期：2026-07-14。

Backlinks