同步失败日志默认不写入/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
fi
done
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=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 在兜底——而那个兜底逻辑的日志，得你自己去记。
