linux cron时间格式错误最常见问题是字段顺序错（应为“分 时 日 月 周”）或符号误用（如/5在老版本中静默失败），例如/2 实为每2分钟而非每2小时，0 /2 才正确。
crontab 时间格式写错导致脚本不执行
最常见的问题不是脚本本身，而是 crontab 行里时间字段顺序或符号用错。Linux 的 cron 时间格式是「分 时 日 月 周」，不是「秒 分 时…」，也不支持 */5 这种写法在某些老版本 crond 中会静默失败。
例如想每2小时同步一次，正确写法是：0 */2 * * *；如果写成 */2 * * * *，实际是每2分钟执行一次——容易误判为“同步太频繁”而怀疑逻辑出错。
-
0 2 * * *：每天凌晨2点（推荐用于耗资源操作） -
30 1,13 * * *：每天1:30和13:30各一次（避开业务高峰） - 周几字段用
0或7都表示周日，但部分系统只认0，统一用0更稳妥 - 避免使用
@daily这类语义别名——它依赖 cron 实现，有些容器环境或最小化系统不支持
rsync 脚本中路径末尾斜杠影响同步行为
rsync 对源路径末尾是否有 / 敏感，直接决定是“同步目录内容”还是“同步目录本身”。比如：
-
rsync -avz /data/ user@host:/backup/→ 把/data/下所有文件复制到/backup/ -
rsync -avz /data user@host:/backup/→ 把整个/data目录（含名字）复制到/backup/data/
多数定时同步场景要的是前者，所以脚本里务必确保源路径带尾部 /，目标路径也带 /（除非你明确需要创建嵌套目录）。漏掉这个细节，会导致多一层目录层级，后续脚本或应用读取路径失败。
SSH 免密登录没生效，rsync 卡在密码提示
即使执行了 ssh-copy-id，仍可能因权限或配置问题无法免密。关键检查点：
- 目标服务器
~/.ssh/authorized_keys文件权限必须是600，目录~/.ssh必须是700，否则 sshd 拒绝读取 - 确认目标服务器
/etc/ssh/sshd_config中PubkeyAuthentication yes和PermitRootLogin（如用 root）设置合理 - 测试命令别用
ssh user@host，而要用rsync --dry-run -avz /tmp/ user@host:/tmp/—— 它会真实走 rsync 的 SSH 流程，比单纯 ssh 登录更能暴露问题 - 如果目标是容器或精简系统，可能压根没开
sshd，此时得换rsync daemon模式或改用scp+sshpass（不推荐，密码明文风险高）
脚本在 crontab 里执行失败，但手动运行正常
根本原因是 cron 环境变量极简：PATH 通常只有 /usr/bin:/bin，没有用户家目录下的 ~/bin 或 /usr/local/bin。所以常见报错是 command not found: rsync 或 ntpdate: command not found。
解决方式不是改全局 PATH，而是脚本开头显式声明：
#!/bin/bash export PATH="/usr/local/bin:/usr/bin:/bin" # 后续调用 rsync、ntpdate 等命令就不再报错
另外注意：
- 脚本中所有路径用绝对路径，
cd切换目录后才用相对路径，否则 cron 执行时工作目录不确定 - 日志重定向必须用完整路径，比如
>/var/log/sync.log 2>&1，不能只写>sync.log - 调试时可在 crontab 行末加
&& echo "$(date) run ok" >> /tmp/cron_debug.log，快速验证是否真被执行
实际部署时，最易被忽略的是 cron 的 SHELL 环境默认是 /bin/sh，不是 /bin/bash。哪怕脚本第一行写了 #!/bin/bash，cron 仍可能用 sh 解析——导致数组、[[ 条件判断等 bash 特性失效。保险做法：在 crontab 里显式指定解释器，或者脚本开头用 set -euo pipefail 尽早暴露语法错误。
