同步任务出错时日志通常不在标准系统日志中，需重点检查stderr输出、显式重定向的日志文件（如/var/log/rsync.err）及journalctl管理的systemd服务日志。
同步任务出错时，日志通常不在标准系统日志里
大多数文件同步工具（如 rsync、inotifywait 脚本、lftp、unison 或自定义定时任务）不会把错误写进 /var/log/messages 或 /var/log/syslog。它们默认只输出到终端或丢弃——除非你显式重定向了 stderr。所以直接 grep "error" /var/log/syslog 很可能一无所获。
真正有用的错误日志，藏在三个地方：
- 同步命令执行时的
stderr输出（如果你没重定向，它就一闪而过） - 你脚本里用
>>或2>显式写入的日志文件（比如/var/log/rsync-backup.log） - systemd 服务管理的同步任务，其日志得用
journalctl查（不是tail -f /var/log/xxx）
查 rsync 类任务的错误日志，重点看这三处
rsync 本身不生成持久日志，全靠你“留痕”。常见错误日志来源如下：
- 如果用了
rsync --log-file=/path/to/rsync.log：直接tail -n 20 /path/to/rsync.log，但注意该日志只记录传输行为，不捕获 shell 层面的权限拒绝、路径不存在等错误 - 如果命令是
rsync ... 2>/var/log/rsync.err：错误全在/var/log/rsync.err，用tail -n 15 /var/log/rsync.err看最新几行 - 如果是 cron 里跑的 rsync，且没重定向 stderr：错误会发邮件给 root（前提是 mail 服务开着），或者被 cron 静默丢弃——这时必须补上
2>&1 >>/var/log/rsync-cron.log
systemd 管理的同步服务，别用 tail 查日志
如果你把同步脚本做成 systemd service（例如 backup.service），它的 stdout/stderr 默认由 journald 接管，/var/log/ 下没有对应文件。
正确查法是：
-
journalctl -u backup.service -n 30：看最近 30 行 -
journalctl -u backup.service --since "2 hours ago"：查两小时内日志 -
journalctl -u backup.service -p err：只显示 error 级别及以上日志（注意：很多 shell 错误不会自动标为 err 级别，所以建议先不加-p） - 如果服务刚失败过，
journalctl -u backup.service --since "1 minute ago" | grep -E "(fail|error|exit|No such)"更快定位
自定义脚本同步失败，第一反应不是翻日志而是看 exit code
很多同步脚本失败后没有日志，但 shell 的 $? 一定非零。在脚本末尾加一句 echo "Exit code: $?" >> /var/log/my-sync.log，比事后猜更有价值。
常见陷阱：
- 脚本里用了
set -e但没配|| true，导致某条命令失败后整个流程中断，后续日志写不进去 - 日志路径权限不对，比如
/var/log/myapp/目录属主是 root，但脚本以普通用户运行，echo "xxx" >> /var/log/myapp/sync.log会静默失败 - 用了
date命令但没加引号：echo $(date) error >> log中的空格会让重定向出错，实际写入的是error文件而不是追加到 log
真正要命的不是日志找不到，而是同步任务根本没配置任何错误捕获机制——这种情况下，连“有没有错”都得靠人工巡检。
