lsyncd启动后无反应的主因是日志未启用或权限不足：需显式配置logfile和loglevel，且运行用户须对源目录有读执行权、目标端有免密ssh权限并预建目标目录。
直接用 lsyncd 就能实现毫秒级触发、低开销的实时同步，但配置错一个参数（比如 delay、excludeFrom 或 rsyncssh 的 host 格式）就会导致同步失败、文件损坏或反复重传。
为什么 lsyncd 启动后没反应？查日志和权限这两步不能跳
绝大多数“启动了但不干活”的问题，根源在日志没开或权限卡死：
-
settings块里必须显式写logfile = "/var/log/lsyncd.log"和loglevel = "Debug"，否则默认不输出任何信息 - 运行用户（通常是
root）必须对源目录有读+执行权限（ls -ld /path/to/source看是否可进入），对目标机器要有免密ssh权限（ssh user@host date能直通） - 远端目标目录（如
/backup）必须提前手动创建好，lsyncd不会自动建目录，也不会报错提示 - 如果用
systemctl start lsyncd失败，先运行lsyncd -nodaemon -pidfile /var/run/lsyncd.pid /etc/lsyncd.conf.lua看终端报错，再查/var/log/lsyncd.log
rsyncssh 模式下 host 和 targetdir 怎么写才不报错？
host 和 targetdir 是两个独立字段，不能合并成一个字符串；且 host 不能带端口或用户，端口和用户必须塞进 ssh 子块或 targetdir 中——这是最常踩的格式坑：
- 正确写法（推荐）：
host = "192.168.1.100"+targetdir = "user@192.168.1.100:/data/backup"+ssh = { port = 3322 } - 错误写法：
host = "user@192.168.1.100:3322"（host不支持冒号分隔）或targetdir = "/data/backup"（缺用户和主机，rsyncssh会连本地） - 远端 shell 必须是真实 shell（如
/bin/bash），不能是/bin/false或/sbin/nologin，否则 SSH 连接建立后立刻断开 - 远端必须已安装
rsync（rsync --version可验证），不需要启动rsyncd服务
如何避免同步 .swp、~ 临时文件和半截写入的文件？
靠 exclude = { "*.swp", "*~" } 不够——这些文件在编辑器刚打开时就触发 inotify 事件，lsyncd 会尝试同步未写完的内容。真正有效的组合是：
- 用
excludeFrom = "/etc/lsyncd_exclude.lst"，并在该文件里写多行过滤规则（支持注释和空行），例如：*~ *.swp *.tmp .git/ *.log
- 设
delay = 5（单位秒）：让变更事件缓存 5 秒，等编辑器写完再批量触发rsync，避免“同步一半的文件” - 设
maxProcesses = 1：防止多个rsync并发争抢同一文件，尤其小文件密集写入时容易出错 - 慎用
delete = true：它会让rsync删除目标端不存在于源端的文件；若只是做备份，建议去掉或改用_extra = {"--ignore-existing"}
systemctl start lsyncd 报 Failed to start LSB 是版本不匹配
新旧版 lsyncd 的 systemd 启动命令不兼容，老配置直接套用会失败：
- 先查版本：
lsyncd --version；若 ≥ 2.2.3，说明已弃用-pidfile参数，改用--pidfile - 修改
/lib/systemd/system/lsyncd.service中的ExecStart=行，例如：ExecStart=/usr/bin/lsyncd --pidfile /var/run/lsyncd.pid /etc/lsyncd.conf.lua
- 改完后必须执行：
systemctl daemon-reload && systemctl restart lsyncd - 注意：新版默认不写 pid 文件，所以
--pidfile是可选的；但如果你依赖 pid 文件做监控或脚本判断，就得显式加上
实际部署中最容易被忽略的是 inotify 事件上限和远端 shell 类型——前者导致大目录首次监控失败（inotify watch limit reached），后者让连接静默中断；这两个点不提前验证，日志里根本不会体现原因。
