Linux怎么查看具体的文件同步任务冲突排查详细报告

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 -a v --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 秒里，其他相关进程到底在做什么。