runuser命令在cron环境下的异常行为问题排查

问题根源 #

手动执行脚本能生成dump文件，但cron任务运行后找不到文件，核心原因是cron的运行环境和交互式shell差异极大：环境变量缺失、工作目录不明确、命令语法细节没处理到位，哪怕syslog显示任务已执行，实际命令可能因为这些问题悄悄失败。

具体修复步骤 #

• 补全时间变量，避免空值解析
  cron默认没有DATE这个环境变量，原命令里的${DATE}会被解析为空，导致文件名变成dump_.sql，甚至直接让命令报错。直接在命令里用date生成时间戳是最稳妥的方式：

  runuser -l postgresql -c 'pg_dumpall -c > dump_$(date +%Y%m%d_%H%M%S).sql'
  

  要是非要用DATE变量，就在cron任务里先定义，注意改用双引号让变量能正常展开：

  DATE=$(date +%Y%m%d_%H%M%S)
  runuser -l postgresql -c "pg_dumpall -c > dump_${DATE}.sql"
  

• 指定绝对路径，防止文件“失踪”
  cron默认在用户主目录（比如root的/root）执行命令，你可能在其他目录查找文件，自然找不到。直接给备份文件指定绝对路径，比如放到专门的备份目录：

  runuser -l postgresql -c 'pg_dumpall -c > /var/backups/postgres_dump_$(date +%Y%m%d).sql'
  

  提前确认/var/backups目录存在，且postgresql用户有写入权限。

• 简化命令，去除多余的echo
  原命令里的echo $(...)完全多余，反而可能干扰命令输出，直接执行runuser命令即可。

• 添加日志，排查隐藏错误
  给cron任务追加日志输出，万一命令出错能直接定位问题：

  runuser -l postgresql -c 'pg_dumpall -c > /var/backups/postgres_dump_$(date +%Y%m%d).sql' >> /var/log/postgres_backup.log 2>&1
  

完整Cron任务示例 #

用crontab -e编辑root的定时任务，比如设置每天凌晨2点执行备份：

0 2 * * * runuser -l postgresql -c 'pg_dumpall -c > /var/backups/postgres_dump_$(date +%Y%m%d).sql' >> /var/log/postgres_backup.log 2>&1

内容的提问来源于stack exchange，提问作者Molybdenum