linux trigger有何限制

在 Linux 中，“trigger” 这个词可能出现在不同的上下文里，限制也完全不同。下面按常见场景说明：

1. systemd 中的 trigger（单元触发）

systemd 里经常用到 triggers、Wants、Requires、udev trigger 等概念。

主要限制：

• 不能替代依赖顺序：Wants= 或 triggers 只是“触发启动”，不保证完成顺序
• 循环触发限制：systemd 会检测单元循环依赖，循环会被拒绝或截断
• udev trigger 限制
  • udevadm trigger 不会重新加载 rules，只是重发事件
  • 对已经“消失”的设备无法触发
  • 某些内核设备不支持 replay
• 用户服务限制
  • 用户级 trigger 受 user@.service 生命周期限制
  • 无登录用户时不会触发

2. inotify / fsnotify 触发器（文件监控）

常用于 inotifywait、systemd.path 等。

限制：

• watch 数量限制

  fs.inotify.max_user_watches
  

  默认通常 8192，容易耗尽
• 不能监控递归目录历史
  • 只报告“之后”的事件
  • 文件在 watch 前已变化不会触发
• 网络文件系统限制
  • NFS、FUSE 很多不支持 inotify
• 原子重命名问题
  • mv 可能不触发预期事件
• 性能限制
  • 大量小文件高频写入会丢事件

3. cron / timer 触发器

（如 systemd.timer）

限制：

• 最小精度
  • cron 一般秒级不支持（除非增强版）
  • systemd.timer 精度受 AccuracySec 影响
• 错过不补
  • 关机期间该触发的不会补跑（除非 Persistent=true）
• 时区问题
  • 本地时区变更可能导致跳触发

4. 硬件 / 内核 trigger（如 GPIO、IRQ）

限制：

• 需要 root / 特定 cap
• 某些中断不能共享
• 高频 trigger 会被内核节流（throttle）
• 用户态响应延迟不可控

5. 数据库 / 应用层 trigger（如 MySQL trigger）

虽不是 Linux 本身，但常跑在 Linux 上：

• 不能跨库事务
• 调试困难
• 性能随行数线性下降

总结一句话

Linux 中的 trigger 大多“只负责通知，不保证顺序、不保证不丢、不保证历史”。

如果你指的是某一种具体 trigger（如 systemd、udev、inotify、kernel event），可以告诉我，我可以给更精确的限制和示例。