lsyncd同步“不实时”根本原因是delay参数默认为1秒且启用事件聚合机制，导致修改后需等待延迟窗口结束才批量触发rsync；inotify队列满或mv/覆盖写等操作亦无法捕获。
为什么 lsyncd 同步看起来“不实时”
lsyncd 默认不是严格意义上的“秒级触发”，它依赖 inotify 事件 + 内部延迟合并机制，常见现象是修改文件后 1–3 秒才同步，甚至偶尔卡住。根本原因在于 delay 参数默认为 1（秒），且 lsyncd 会等待该窗口内更多事件进来做批量处理——这本意是减少 SSH 连接开销，但牺牲了感知上的实时性。
-
delay 0不合法，最小允许值是 1 - 即使设为
delay 1，若连续写入多个小文件，lsyncd 可能仍会攒批发送，导致首文件延迟 >1s - inotify 队列满（
Inotify watch limit reached）会导致事件丢弃，后续变更完全不触发同步
怎样压到接近“秒级触发”的实际效果
关键不是调低 delay，而是缩短事件从产生到执行 rsync 的路径。需组合调整三项：
- 把
delay设为1（最低合法值），并显式关闭聚合：maxProcesses = 1、maxDelays = 1 - 在
rsyncOpts中加--inplace和--no-whole-file，避免 rsync 先建临时文件再重命名的额外耗时 - 确保源目录 inotify 句柄充足：临时扩容用
echo 65536 > /proc/sys/fs/inotify/max_user_watches，永久生效写入/etc/sysctl.conf
示例片段（/etc/lsyncd.conf）：
settings {
logfile = "/var/log/lsyncd.log",
statusFile = "/var/log/lsyncd.status",
statusInterval = 1,
nodaemon = false,
}
sync {
default.rsync,
source = "/data/web/",
target = "user@192.168.1.100:/data/web/",
delay = 1,
maxProcesses = 1,
maxDelays = 1,
rsyncOpts = {"--inplace", "--no-whole-file", "--compress"},
}
哪些操作不会被 inotify 捕获，导致“改了却不同步”
lsyncd 依赖 inotify，而 inotify 只监听内核发出的文件系统事件。以下行为不会触发同步：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 通过
mv将文件移入监控目录：仅触发IN_MOVED_TO，但 lsyncd 默认只响应IN_CREATE和IN_MODIFY；需启用inotifyInit = { enable = true }并确认版本 ≥ 2.2.2 - 覆盖写入大文件（如数据库 dump）：若进程先
truncate()再分块写，inotify 可能只上报一次IN_MODIFY，lsyncd 看到的是“空文件被改”，同步出错 - 挂载点变更（如 NFS 重挂）、SELinux 上下文变更、硬链接创建：inotify 完全无感知
调试同步失败时，第一步必须看什么日志
别急着改配置，先确认事件是否真正到达 lsyncd。最有效的方式是开两个终端：
- 终端 1：运行
lsyncd -nodaemon -logall /etc/lsyncd.conf，观察控制台输出的 inotify 事件和 rsync 命令 - 终端 2：手动触发变更，例如
echo "test" > /data/web/test.txt && sleep 0.5 && ls -l /data/web/test.txt
重点关注三类输出：
- 含
inotify: IN_CREATE或IN_MODIFY的行 → 表明 inotify 正常收事件 - 含
Executing command和完整rsync命令的行 → 表明 lsyncd 已调度同步 - 含
rsync exited with code 23或Connection refused→ 问题在 rsync 层，与 lsyncd 触发逻辑无关
如果第一类日志完全没出现，说明 inotify 层已断，立刻检查 max_user_watches 和目录是否被其他 inotify 程序占满。
