linux中不存在“文件同步任务冲突日志”标准概念，冲突信息由rsync、rclone、syncthing等工具在stderr、专用日志或目标目录中生成，需针对性捕获和分析。
Linux 没有“文件同步任务冲突日志”这个标准概念——所谓“冲突”，通常不是内核或系统自动记录的独立日志类型，而是由具体同步工具（如 rsync、rclone、syncthing、lsyncd）在运行失败时输出的错误信息，或由应用层检测到文件内容/时间戳不一致后主动记录的诊断日志。
rsync 同步失败时怎么看真实错误
rsync 本身不生成“冲突日志文件”，但它的退出状态和 stderr 输出就是关键线索。常见误判是只看 rsync 命令是否返回 0，却忽略它实际打印的警告或拒绝操作的行。
- 必须加
--verbose或-v，否则很多跳过/冲突细节被静默丢弃 - 重点捕获 stderr：
rsync -av --delete src/ dst/ 2>&1 | grep -E "(conflict|skip|failed|is newer|stale)" - 如果用 cron 调度，务必重定向 stderr 到文件，例如：
rsync -av src/ dst/ 2>>/var/log/rsync-backup.log -
--itemize-changes会逐项显示哪些文件被更新、删除、跳过，比单纯-v更细粒度，适合排查“为什么没同步”
rclone sync 冲突提示藏在 --log-file 和 --dry-run 结果里
rclone 的“冲突”逻辑更明确：当目标端存在同名文件但修改时间/大小不一致，且未指定 --update 或 --force 时，它默认跳过并记录为 “NOTHING TO DO” 或 “skipping file due to modtime mismatch”。这类信息不会出现在 stdout，必须显式开启日志。
- 加
--log-file=/tmp/rclone-sync.log，否则所有 warning/error 都只打到 stderr - 先跑
--dry-run+--log-level INFO，观察哪些文件被标记为NOT IN SYNC或MODTIME DIFFERS - 注意
--checksum和--size-only会影响“冲突”判定逻辑：前者比对内容哈希，后者只看大小，误报率差异很大 - rclone 不会自动覆盖或报错中断，所以“无输出”≠“成功同步”，得查日志里有没有
INFO级别的 skip 提示
syncthing 日志里搜 conflict 关键字要带上下文
syncthing 是少数真正实现“冲突文件自动重命名”的工具（生成 xxx.conflict-xxxxx 文件），但它默认日志级别是 WARNING，conflict 相关消息往往在 INFO 级别才出现，容易漏看。
- 启动时加
-log-level=info，或改配置中"logLevel": "info" - 日志路径取决于部署方式：
/var/log/syncthing.log（systemd）、~/.local/state/syncthing/logs/（用户模式） - 直接搜
conflict可能匹配过多（比如路径含 conflict 字串），建议组合过滤：grep -i "conflict.*create\|created.*conflict" /var/log/syncthing.log - 注意：syncthing 的“冲突”本质是两个设备同时修改同一文件，它不解决语义冲突，只做文件级备份。真要定位谁改了什么，得靠它的
modelAPI 或 Web UI 的“历史”页
别依赖 /var/log/messages 查同步冲突
系统日志（/var/log/messages、journalctl）几乎不会记录 rsync/rclone/syncthing 的业务级冲突。除非同步进程因权限、磁盘满、挂载丢失等系统级问题崩溃，内核或 systemd 才会记一条 Failed with exit code X。这类日志只能告诉你“坏了”，不能告诉你“哪里冲突了”。
-
journalctl -u rclone-backup.service --since "2 hours ago"只能看到服务启停和 panic，看不到文件级差异 -
dmesg更无关——那是硬件/驱动/内存问题的日志源，和文件内容同步无关 - 真正该盯的是同步工具自己的日志路径、stderr 输出、以及目标目录下是否意外出现
.conflict-或.sync-conflict-类临时文件
最常被忽略的一点：很多同步脚本用 || true 吞掉非零退出码，或把 stderr 重定向到 /dev/null，结果“看起来每天都在跑”，其实半年没成功过一次。检查你的 cron 或 systemd service 文件里有没有这两样东西。
