Linux怎么查看具体的文件同步失败重试日志

同步失败日志去哪了？别在系统日志里白费力气

先说说几个关键点，省得你一头扎进系统日志里翻半天，结果啥也没找到。

默认情况下，rsync、unison、lftp 或者 inotifywait + scp 这些同步工具，根本不会把失败重试的细节写进系统日志——/var/log/messages 也好，journalctl 也罢，它们连眼皮都不抬一下。错误和重试行为，只输出到 stderr 或者你指定的日志文件里。换句话说，没显式配置，就根本没落盘。

所以，别指望 grep "retry" /var/log/syslog 能出个结果，那多半是空的。真正要查的，是同步命令自己产生的日志路径，或者它 stdout/stderr 的捕获位置。

如果上来就卡住了，先确认这几点：

• 用的是哪个同步工具？rsync 最常见，但 lftp 的重试逻辑完全不同。
• 启动命令是否带了 --log-file=、-o LogLevel=DEBUG、-v --debug 这类参数？
• 如果通过 systemd 启动，查 systemctl status sync-unit 和 journalctl -u sync-unit -n 100。但注意：只有重定向了 stdout/stderr 到 journal 的服务，才会留下重试记录。

rsync 的失败重试日志，得手动开

rsync 本身默认不重试——它失败就退出，干净利落。所谓的“重试”，其实是外层脚本或者 systemd Restart=on-failure 在背后悄悄兜底。要看到每次失败+重试的完整上下文，必须让它把所有输出都记下来：

• 加 -v --log-file=/path/to/rsync.log：记录传输过程、跳过原因、IO 错误等。但注意，它不会出现“第几次重试”这样的字样。
• 加 --debug=all（仅调试用）：输出 socket 连接尝试、超时、重连动作，但日志极冗长，且只输出到终端，需要配合 2>&1 | tee 才能捕获。
• 真正重试逻辑在 wrapper 脚本里？那就得看脚本里有没有 echo "$(date) - retry #${i}" >> /var/log/sync-retry.log 这类显式记录。

举个最小可行的脚本例子，带重试计数的那种：

for i in {1..3}; do
  if rsync -a vz --delete user@host:/remote/ /local/ 2>>/var/log/rsync-full.log; then
    echo "$(date) - success after $i attempts" >> /var/log/sync-summary.log
    exit 0
  else
    echo "$(date) - failed attempt #$i" >> /var/log/sync-summary.log
    sleep 5
  fi
done

journalctl 查不到重试日志？看看 systemd 服务配置

如果你把同步任务做成了 systemd service，但 journalctl -u my-rsync.service 里看不到重试信息，大概率是因为以下几个原因：

• 没设置 StandardError=journal（默认是 inherit，继承父进程 stderr，常常指向 /dev/null）
• 没加 Restart=on-failure 或 RestartSec=10，根本没触发重试
• 重试时，脚本每次都 > /tmp/log 而不是 >>，旧日志被覆盖

正确的 service 片段应该包含这些：

[Service]
Type=oneshot
ExecStart=/usr/local/bin/sync-wrapper.sh
Restart=on-failure
RestartSec=30
StandardOutput=journal
StandardError=journal

排查时，优先检查这三个地方，别大海捞针

别在全局日志里翻来覆去，按顺序来：

• 同步命令本身是否写了日志文件？看启动参数里的 --log-file、-o logfile=、2>/var/log/xxx.err。
• 执行该命令的用户 home 目录下，有没有临时 log？比如 ~/.rsync-log、~/sync-errors.log。
• 如果是 cron 触发，检查 MAILTO 是否开启。失败时，邮件里常常会包含 stderr 内容。

真正的重试细节，几乎从不进 /var/log/ 树，除非你明确把它导向那里。最容易被忽略的一点是：你以为工具自带重试，其实只是 shell 循环或 systemd 在兜底——而那个兜底逻辑的日志，得你自己去记。