systemd.path 怎样按文件变化触发服务

创建一个 .path 单元，用 PathChanged=绝对路径 监听文件，并通过 Unit= 指定要启动的服务；处理任务适合写成执行完就退出的 Type=oneshot 服务。然后启动并启用 .path 单元，文件变化就能成为服务的激活条件。

我把这种组合看成“文件状态提醒器”：监听器负责发现需要处理的迹象，服务负责重新读取当前状态。它适合配置刷新、小型索引更新等任务，但不能据此承诺每次写入都可靠地对应一次处理。以下是原创演示配置，未在本机执行。

官方文档：https://www.freedesktop.org/software/systemd/man/latest/systemd.path.html。服务配置：https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html。管理命令：https://www.freedesktop.org/software/systemd/man/latest/systemctl.html。

模式：监听条件与处理任务分开

不要把业务命令塞进 .path 文件。本文的 demo-fingerprint.path 声明监听关系，demo-fingerprint.service 描述执行方式，demo-fingerprint.sh 才完成业务动作。虽然同名 .path 默认可以关联同名 .service，显式写 Unit= 更方便读者理解两者的绑定。

输入是 /var/lib/demo-input/config.txt，输出是 /var/lib/demo-output/config.sha256。两个目录分开，避免处理服务的写入再次进入自身监听范围。这个结构同样适用于任务产生索引、缓存或报告的情况。

适用压力：需要的是状态更新提醒

先确认需求是“当前文件变了就处理当前内容”，还是“每次提交都必须有单独确认”。前者可以采用这个组合；后者通常还需要明确的队列、记录标识和完成状态。把文件系统通知当成业务事务，会让遗漏和重复处理的责任变得模糊。

PathChanged 关注变化，写入打开的文件在关闭后可触发；PathModified 还包含普通写操作的通知语义。即使用更敏感的监听条件，也不意味着处理程序一定看见上游每个中间版本。写入方应有明确的交付约定，处理方应能够重复处理同一份最终状态。

典型实现：文件监听配合 oneshot 服务

在演示主机上把第一个文件保存为 /etc/systemd/system/demo-fingerprint.path：

[Unit]
Description=Watch demo configuration changes

[Path]
# 监听这个绝对路径的变化，使用配套服务处理。
PathChanged=/var/lib/demo-input/config.txt
Unit=demo-fingerprint.service

[Install]
# 启用的是监听单元，而不是一次性任务本身。
WantedBy=multi-user.target

把第二个文件保存为 /etc/systemd/system/demo-fingerprint.service：

[Unit]
Description=Record current demo configuration fingerprint

[Service]
# 任务执行完退出，不使用 RemainAfterExit=yes 保持 active。
Type=oneshot
ExecStart=/usr/local/libexec/demo-fingerprint.sh

脚本保存为 /usr/local/libexec/demo-fingerprint.sh：

#!/bin/sh
# 生成当前文件的指纹；输出目录与监听目录分离。
set -eu
/usr/bin/sha256sum /var/lib/demo-input/config.txt > /var/lib/demo-output/config.sha256
# 标准输出进入该服务日志，便于读者观察任务完成。
printf '%s\n' '当前配置指纹已记录'

脚本读取当前文件，生成 SHA-256 指纹。该命令只是演示处理动作，不是可靠提交协议；运行过程中并发改写文件仍需上游协调。请确认发行版中的 sha256sum 路径，若路径不同应同步调整。示例系统服务未配置 User=，会按系统管理器的默认身份执行；正式部署应使用专用账号，并授予所需目录权限。

# 在演示用的 systemd Linux 主机上准备独立目录。
sudo install -d /var/lib/demo-input /var/lib/demo-output /usr/local/libexec
# 首次创建输入文件；在启用监听前准备好基础状态。
printf '%s\n' 'mode=preview' | sudo tee /var/lib/demo-input/config.txt
# 按正文路径保存脚本和两个 unit 后，授予脚本执行权限。
sudo chmod 0755 /usr/local/libexec/demo-fingerprint.sh
sudo systemctl daemon-reload
# 开机启用并立即启动监听单元。
sudo systemctl enable --now demo-fingerprint.path
# 可手动运行一次服务，为现有输入生成初始指纹。
sudo systemctl start demo-fingerprint.service

启用 PathChanged 监听并不会因为文件原本就存在而必然执行一次，所以这里单独提供初始化补跑命令。文件和脚本都先准备好，再启动监听，可以避免把缺少基础文件误当成监听故障。

# 修改文件并关闭写入，给监听条件提供一次变化。
printf '%s\n' 'mode=published' | sudo tee /var/lib/demo-input/config.txt
# 观察监听状态和一次性服务的最近执行信息。
systemctl status demo-fingerprint.path demo-fingerprint.service
journalctl -u demo-fingerprint.service -n 20 --no-pager
# 输出存在且内容更新，才说明这个演示任务完成了它的工作。
cat /var/lib/demo-output/config.sha256

一次性服务成功退出后显示 inactive 并不一定是异常。读者应结合最近退出状态、服务日志与指纹文件判断结果；.path 仍应处于监听状态。本文没有生成这些命令的实际终端输出。

反例：存在条件、常驻进程与远程文件

DirectoryNotEmpty 适合表达目录仍有待处理文件，但处理服务必须真正改变待处理状态。若每次运行只是查看目录而不消费任何项目，退出后条件依然成立，就可能进入反复启动。这个例子不是建议你把文件变化需求替换为目录队列。

后果：幂等、可观察与失败恢复

这个模式把执行交给 systemd 管理，日志和退出状态也跟随服务单元。代价是处理程序必须面对重复激活、变化合并和自身失败。建议让任务从当前输入重新计算结果，而不是简单累加一个不可逆动作；需要对外产生副作用时，应自行建立幂等标识。

监听条件持续满足且任务快速结束时，服务可能再次启动；启动频率限制可以阻止忙循环，命中限制的失败也可能传播到 path 单元。不要只执行 reset-failed 就认为根因已经修复，应先改正持续触发条件或失败脚本。

# 先修复脚本、路径或权限，再清除实际出现的失败状态。
sudo systemctl reset-failed demo-fingerprint.service demo-fingerprint.path
# 如输入仍需处理，显式补跑一次任务，再恢复监听。
sudo systemctl start demo-fingerprint.service
sudo systemctl restart demo-fingerprint.path

上面的命令是故障修复后的恢复操作，不是为了掩盖反复失败。手动补跑当前状态很有价值，因为监听变化本身并不提供持久的待处理任务账本。

判断清单与常见疑问

采用前可以逐项确认：输入是否在本地可监听文件系统；任务能否重复执行；输出是否离开监听范围；服务是否会及时退出；初始状态和失败后的补跑由谁负责。只要其中一项需要“每条事件必须有凭证”，就应补齐对应协议。

修改 .path 后需要什么操作？

让管理器重新读取单元定义，再重启监听单元，使监听配置按新定义建立。daemon-reload 负责重读定义，不能直接等同于所有正在运行单元都自动按新状态重启。

为什么不启用 .service？

本文让监听器决定何时激活任务，因此开机启用的是 .path。这个服务没有单独配置 Install 段；初始化时可以手动 start 一次。

能同时监听多个路径吗？

可以配置多条支持的监听条件，但任务应自己知道如何读取所需当前状态。不要假设 ExecStart 会自动收到导致变化的文件名参数。

编辑器采用临时文件替换保存怎么办？

保存方式会影响文件系统事件，应按实际输入交付方式选择监听文件或目录的边界。若监听目录，要避免把无关文件和输出纳入范围；也不能把目录监听理解成递归追踪所有子目录的可靠业务队列。