crontab任务未执行时，应先检查/var/log/cron日志确认调度行为，再结合邮件输出、重定向日志、systemd journal或rsync进程状态综合排查路径、权限、环境变量及同步逻辑问题。
Linux 没有“同步任务冲突日志”这种标准日志类型——所谓“冲突”，通常是 crond、rsync、systemd timer 或应用层同步逻辑出错时留下的痕迹，得靠组合排查。
crontab 任务没执行？先看 /var/log/cron
这是最常见场景：你写了 rsync 或 scp 同步脚本放进 crontab，但没跑或中途卡住。
-
/var/log/cron记录了 crond 调度行为本身：是否触发、是否 fork 出子进程、是否因权限/路径问题跳过执行 - 用
sudo tail -n 50 /var/log/cron查最近记录；若该文件为空，说明 rsyslog 或 systemd-journald 没启用 cron 日志（需检查/etc/rsyslog.d/50-default.conf是否包含cron.*配置） - 注意：CentOS/RHEL 默认启用，Ubuntu/Debian 可能默认关闭，需手动开启
sudo systemctl restart rsyslog
同步命令自己报错？查 stdout/stderr 输出目标
crontab 默认把命令的 stdout 和 stderr 发到本地邮箱（/var/spool/mail/$USER），而不是写进系统日志。
- 运行
tail -f /var/spool/mail/$(whoami)看是否有被截断的错误输出（比如rsync: failed to connect、Permission denied） - 更可靠的做法是在 crontab 条目末尾重定向：
0 * * * * /path/to/sync.sh >> /var/log/my-sync.log 2>&1 - 避免用
2>/dev/null掩盖错误；rsync的-v或--itemize-changes参数能暴露文件跳过、权限变更等隐性“冲突”
systemd timer 同步失败？用 journalctl 过滤 unit 名
如果你用 systemd 管理定时同步（如 my-backup.timer + my-backup.service），日志全在 journal 里。
-
journalctl -u my-backup.service --since "1 hour ago"查服务实际执行输出 -
journalctl -u my-backup.timer看 timer 是否按时触发、是否被 disabled 或 masked - 关键点：
systemd不会自动捕获子进程的 stderr，如果 service 文件里没设StandardError=journal，错误可能直接丢弃 - 检查 service 文件中
Type=设置：用Type=oneshot+RemainAfterExit=yes才适合一次性同步任务；Type=simple容易被误判为 hang 住
rsync 或 lsyncd 自身状态？别只盯日志，看进程和锁文件
很多“同步冲突”根本不会记日志，而是表现为进程僵死、临时文件残留、或端口/文件锁未释放。
-
ps aux | grep rsync看是否有长时间运行的 rsync 进程（尤其注意是否卡在waiting for file） -
ls -l /var/run/lsyncd.pid或/tmp/rsync.lock类文件是否存在且未被清理 -
lsof -i :22或lsof -p $(cat /var/run/lsyncd.pid)查同步进程是否卡在某个 socket 或文件句柄上 -
rsync的--timeout=30和--contimeout=10必须显式设置，否则网络波动时会无限等待，看起来像“冲突”
真正麻烦的不是日志在哪，而是同步逻辑本身没做幂等或排他控制——比如两个 rsync 同时往同一目录写，或没加 --delete-after 导致中间态不一致。日志只是线索，得结合进程状态、锁机制和命令参数一起读。
