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

同步失败日志默认不写入/var/log/messages或journalctl，需显式配置--log-file或重定向stderr；rsync本身不重试，重试逻辑在脚本或systemd中，其日志须手动捕获并落盘。

同步失败日志通常不在通用系统日志里

默认情况下，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 -avz --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  fidone

journalctl 查不到重试日志？先确认 systemd 服务是否捕获 stderr

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

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

正确 service 片段应包含：

[Service]Type=oneshotExecStart=/usr/local/bin/sync-wrapper.shRestart=on-failureRestartSec=30StandardOutput=journalStandardError=journal

排查时优先检查三个地方

别在全盘日志里大海捞针。按顺序查：

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

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