crontab任务默认不记录输出，stdout和stderr发往用户邮件（/var/spool/mail/root），无邮件服务则丢失；/var/log/cron仅记录调度动作，不记录命令执行结果；必须显式重定向（如>> /path/log 2>&1）或用logger写syslog才能可靠留存输出。
crontab 任务输出不记录？默认行为要搞清
crond 执行任务时，标准输出（stdout）和标准错误（stderr）默认不会写入文件，而是尝试发给对应用户的系统邮件（/var/spool/mail/root）。如果没配邮件服务（比如 sendmail 或 postfix），这些输出就丢了——你查 /var/log/cron 只能看到“已调度”，看不到命令实际跑出啥。
-
/var/log/cron只记录 crond 自身的调度动作（如“RUNNING”“RELOAD”），不记录脚本或命令的执行结果 - 用户级任务（
crontab -e）的输出默认走 mail，不是日志文件 - 系统级任务（
/etc/crontab或/etc/cron.d/）也一样，除非显式重定向
用 > 和 2>&1 重定向输出到文件
最直接、最可控的方式是手动把 stdout 和 stderr 捕获到指定文件。注意：必须用绝对路径，且目标目录要有写权限。
- 覆盖写入（每次新内容替换旧内容）：
0 2 * * * /backup.sh > /var/log/backup.log 2>&1 - 追加写入（保留历史，推荐）：
*/5 * * * * /check.sh >> /var/log/check.log 2>&1 - 分开记录 stdout 和 stderr：
30 8 * * * /deploy.sh > /var/log/deploy.out 2> /var/log/deploy.err - 避免日志无限增长，可配合
logrotate或在脚本里做清理（比如find /var/log -name "backup.log" -mtime +7 -delete）
/etc/crontab 中的 MAILTO 不等于日志记录
/etc/crontab 开头常有 MAILTO=root，这只会把输出发邮件，不是写日志。而且很多生产环境根本没启邮件服务，结果就是“静默失败”。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 别依赖
MAILTO做结果归档，它不可靠、难检索、易被忽略 - 若真要用邮件，确保
sendmail或ssmtp已安装并配置，且防火墙放行 SMTP 端口 - 更稳妥的做法：脚本内部用
logger写 syslog：echo "backup started" | logger -t backup-script，这样能进/var/log/messages并被集中收集
systemd timer 的日志天然可查，但需主动启用
如果你用的是 .timer + .service 方式（而非 crontab），它的输出默认由 journald 收集，但得确认 service 单元没禁用日志：
- 检查
StandardOutput和StandardError是否为journal（默认就是，不用改） - 用
journalctl -u your-service.service -n 50查最近 50 行 - 加
ExecStartPre=/bin/date >> /var/log/your-task.log也能手动打时间戳 - 注意：journald 日志默认只存内存或有限磁盘空间，长期归档仍需导出或配置
/etc/systemd/journald.conf
真正容易被忽略的是：重定向符号前后不能有空格（比如 >/var/log/a.log 是错的，必须是 > /var/log/a.log），还有脚本里用相对路径（如 ./parse.py）在 crond 下大概率失败——这些细节一错，日志就空着，你还以为任务根本没跑。
