linux无内置同步冲突报告机制，所谓“冲突”实为上层工具（如rsync）执行失败，需结合-v日志、退出码（如23为io错误）、journalctl -u服务名及lsof/inotifywait等工具分层排查。
Linux 没有内置的“文件同步任务冲突排查报告”这种现成的、带汇总摘要的详细报告机制。所谓“同步任务冲突”，通常不是内核或文件系统层的统一事件，而是上层工具（如 rsync、unison、systemd-synd、lsyncd 或云同步客户端）在执行时因权限、路径、时间戳、并发写入等导致的失败——这些失败日志分散在各自进程输出、systemd journal 或自定义日志文件中。
怎么看 rsync 同步失败的具体原因
rsync 是最常用也最容易误判“冲突”的工具。它本身不检测语义冲突（比如两个编辑器同时改同一行），只做文件级覆盖或跳过；所谓“冲突”其实是执行失败或行为不符合预期。
- 必须加
-v（verbose）和--log-file=xxx才能捕获完整过程，例如：rsync -av --delete --log-file=/var/log/rsync-backup.log /src/ user@host:/dst/ - 失败时直接看退出码：
echo $?——23表示文件 IO 错误（如磁盘满、权限拒绝），24表示文件被忽略（通常是--exclude或属性不匹配），1表示语法或参数错误 - 关键线索藏在日志末尾：搜索
rsync error:、Permission denied、No space left on device、file has vanished（源文件在传输中被删） - 避免静默覆盖：加
--ignore-existing或--update可防止目标已有新文件时被源覆盖，这常被误认为“冲突”
怎么查 systemd 定时同步服务的实际报错
如果用 systemctl start sync-job.service 或 timer 触发同步，失败不会自动写进全局日志，得主动挖。
- 先确认服务状态：
systemctl status sync-job.service，重点看Active:行和最后一段journalctl提示 - 查完整日志：
journalctl -u sync-job.service -n 100 -o short-precise（-n 100取最近 100 行，-o short-precise带毫秒级时间戳） - 若服务以非 root 用户运行，必须加
--user参数：journalctl --user -u sync-job.service - 常见陷阱：服务脚本里用了相对路径（如
cd ~/backup && rsync ...），但 systemd 的WorkingDirectory默认是/，导致路径错误却不报具体文件名
怎么定位多个进程同时写同一文件造成的“同步冲突”
这不是同步工具的问题，而是应用层竞争条件（race condition）。内核不会报“同步冲突”，但你会看到文件内容损坏、大小异常、或 lsof 显示多个写者。
- 用
lsof +D /path/to/sync/dir查所有打开该目录下文件的进程，重点关注TYPE为REG且MODE含w（写）的条目 - 过滤正在写入的文件描述符：
lsof -d "txt,w" | grep "/path"（txt表示可执行映射，w表示写模式） - 检查文件锁：
lslocks | grep "/path/file"，看是否有WRITE锁被不同 PID 持有 - 最直接证据：用
inotifywait -m -e modify,move_self,delete_self /path/file监听，再手动触发一次“同步”，观察是否有多次 modify 事件来自不同 PID
真正的难点不在“怎么看”，而在“怎么确定哪一层出的问题”：是 rsync 参数写错了？是 systemd service 文件里漏了 Environment=？还是两个 cron job 都在往同一个临时目录写？没有统一报告，就得按工具链一层层往下敲命令，而且必须结合时间戳对齐日志——别只看最新一条错误，要查它前 5 秒内其他相关进程在干什么。
