Linux Trigger 与 Systemd 的关系
概念澄清
- 在 Linux 运维语境中，**Trigger（触发器）**通常指“当某事件发生时自动执行操作”的机制。它可以由多种技术实现，例如内核的 inotify（文件系统事件）、cron/Systemd Timers（时间事件）、以及 systemd 的按需/事件驱动能力（服务、套接字、路径、设备等单元的事件与依赖）。因此，systemd 并非唯一提供“触发”能力的组件，但它是现代发行版里最常用、与系统服务生命周期深度集成的“事件驱动引擎”。
核心关系
- systemd 将“触发”抽象为若干可组合的单元类型与机制，使系统能够在“事件→动作”的链路上进行编排：
- .path 单元：监控文件/目录的创建、删除、修改等，满足条件即可激活关联服务（典型替代 inotifywait 的常驻方案）。
- .socket 单元：基于套接字的“按需启动”（socket activation），有连接到来时才拉起服务，减少常驻占用。
- .device 单元：基于内核 uevent/设备热插拔事件触发相应服务或动作。
- .timer 单元：替代 cron 的定时触发，支持单调时钟、日历时间、时区与“错过后补执行（Persistent）”等能力。
- 依赖与顺序控制：通过 Wants/Requires/After/Before/Condition… 等字段，把“事件/状态”转成“启动/停止顺序”，实现复杂的依赖编排。
- 日志与观测：借助 journald/journalctl 统一记录事件与动作，便于排查“为何未触发/何时触发”。
常见实现方式对比
| 触发源/场景 |
systemd 机制 |
传统/其他工具 |
适用要点 |
| 文件系统变化 |
.path 单元 |
inotifywait + 循环脚本 |
常驻、系统级集成、依赖管理友好 |
| 定时任务 |
.timer 单元 |
cron |
日历/单调时钟、时区、Persistent、日志统一 |
| 网络就绪后启动 |
依赖 network-online.target 并配合 Wants/After |
手动 sleep/轮询 |
更可靠地等待网络可用 |
| 按需启动服务 |
.socket 单元（套接字激活） |
xinetd/常驻守护 |
有连接才启动，节省资源 |
| 设备热插拔 |
.device 单元 |
udev 规则 + 执行脚本 |
与设备生命周期绑定 |
上述机制共同构成了 systemd 的“事件驱动/按需启动”能力版图，是“Trigger”理念在系统服务管理中的主流落地方式。
实践要点
- 使用 .path 替代 inotifywait 长驻脚本：定义监控路径与事件，关联目标 .service；修改单元后执行 systemctl daemon-reload，用 journalctl -u 观察触发与执行。
- 使用 .timer 替代 cron：为任务编写 .service（定义动作）与 .timer（定义何时触发），启用定时器单元（如 systemctl enable --now mytask.timer），需要时开启 Persistent=true 以补跑错过的任务。
- 事件/状态触发的典型模式：在服务的 [Unit] 中使用 After=、Wants= 指向目标（如 network-online.target），必要时结合 .path/.socket/.device 等单元把“事件”转成“启动”。
易混概念
- MySQL Trigger 属于数据库内部的行级/语句级事件机制，与操作系统层面的 systemd 触发器无关；二者同名但领域完全不同。