系统级定时任务错误输出必须显式重定向，否则默认丢弃；crontab中2>不生效主因是环境变量缺失、目录不可写或路径不存在；系统级任务应使用/etc/crontab或/etc/cron.d/，格式含用户字段且重定向需紧贴命令末尾。
系统级定时任务的错误输出必须显式重定向，否则默认丢进 /dev/null，且不会记录到任何地方 —— 这是绝大多数排查失败的根本原因。
crontab 中 2> 重定向不生效的常见原因
你在 crontab -e 里写了 2> /var/log/myscript.err 却发现文件始终为空，大概率不是语法错，而是以下几点：
- 脚本本身没触发错误（比如命令路径写错、变量未定义、权限不足），但你误以为该报错；
- crond 环境变量极简（
PATH=/usr/bin:/bin），脚本里用的命令如python3或jq找不到，此时错误由 shell 报出，但若没加2>，就直接消失； - 用了
2> file但目标目录（如/var/log/）对运行 crond 的用户（通常是 root）不可写 —— 注意：不是脚本所有者，而是 crontab 所属用户； - 写了
2> /path/to/err.log，但没确认该路径存在，crond 不会自动创建父目录。
root 用户的系统级 crontab 必须用 /etc/crontab 或 /etc/cron.d/
普通用户执行 crontab -e 写的规则走的是 /var/spool/cron/<user></user>，而系统级任务（尤其是需要 root 权限或影响全局的）应走 /etc/crontab 或 /etc/cron.d/ 下的独立文件。这两处支持第6字段指定运行用户，也更利于统一管理错误流向：
CentOS Linux 7.9.2009
下载
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
-
/etc/crontab格式是：分 时 日 月 周 用户 命令，例如：0 2 * * * root /opt/scripts/backup.sh >> /var/log/backup.log 2>&1； -
/etc/cron.d/myjob文件内容格式同上，但需确保文件权限为644、属主为root，且文件名不含点（.）或波浪线（~），否则 cron 会忽略它； - 在这些位置写重定向时，
2>&1必须紧贴命令末尾，中间不能换行或空格断开；&>> /path/log在 CentOS 7 的 cron 中不被识别，只认> /path/log 2>&1或>> /path/log 2>&1。
验证错误是否真被捕获的三步检查法
别只看日志文件有没有生成，要确认“错误”确实发生了且进了文件：
- 手动模拟错误：在脚本末尾加一行
ls /nonexistent/path 2>&1，再执行脚本，看错误行是否出现在重定向目标中； - 查 cron 自身日志：
grep CRON /var/log/cron，确认该任务是否真正触发（常见失败是 cron 没读到新规则，需等下一分钟或重启crond）； - 临时把错误重定向到
/dev/tty1（仅调试）：2>/dev/tty1—— 若有 root 登录的图形终端，错误会弹出来，能快速验证是否捕获成功（注意：生产环境禁用）。
最常被忽略的一点：crond 启动时读取配置，但不会实时 reload /etc/cron.d/ 下新增文件。改完后要么等最多一分钟，要么执行 systemctl reload crond（CentOS 7 支持），而不是 restart —— 后者会中断正在运行的任务。
