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 目录下，是否存在临时日志？例如 ~/.rsync-log、~/sync-errors.log。
• 如果是 cron 触发，检查 MAILTO 是否开启。失败时，邮件中通常会包含 stderr 内容。

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