crontab -l 永远看不到系统级定时任务，因其不读取 /etc/crontab 或 /etc/cron.d/；系统级任务通过 /etc/crontab（含执行用户字段）、/etc/cron.d/ 下独立文件、/etc/cron.hourly 等脚本目录由 run-parts 调用，且需检查 cron 服务状态与日志。
只看 crontab -l 永远看不到系统级定时任务——它压根不读 /etc/crontab 或 /etc/cron.d/，这两处是独立于用户 crontab 的配置体系。
查 /etc/crontab 主配置文件
这是系统级任务的主入口，格式和用户 crontab 不同：多一列「执行用户」，命令从第六字段开始。
- 运行
sudo cat /etc/crontab，重点看第五列（用户名）和第六列之后（命令），例如0 2 * * * root /usr/bin/logrotate /etc/logrotate.conf中的root就是执行身份 - 别漏掉文件开头的
SHELL、PATH和MAILTO设置——这些会影响所有后续任务的环境 - 某些发行版（如 Alpine）默认不带此文件，
ls /etc/crontab返回空不代表没系统任务，可能全在/etc/cron.d/里
扫 /etc/cron.d/ 下的第三方任务
软件包（比如 certbot、logrotate、anacron）安装时会往这里写独立配置片段，每行都带执行用户字段，且不走 crontab 命令管理。
- 先列文件：
sudo ls /etc/cron.d/，注意文件名含点（如certbot.conf）会被 cron 忽略，只认无扩展名或以.cron结尾的 - 逐个查看：
sudo cat /etc/cron.d/certbot，别只看文件名——0hourly这种名字看不出用途，必须打开确认逻辑 - 旧版 cron 不解析软链接，如果看到
ls -l输出里有->，得sudo cat目标文件本身，而不是链接
别跳过 /etc/cron.hourly 等脚本目录
这些不是 crontab 表达式，而是由 run-parts 按周期调用的可执行脚本，完全绕过 cron 解析引擎，但实际执行权重更高。
- 检查是否存在：
sudo ls /etc/cron.daily/，常见有logrotate、apt（Debian）、0yum-hourly-updates（RHEL） - 脚本必须有
+x权限，否则run-parts直接跳过：sudo stat -c "%a %n" /etc/cron.daily/logrotate - 内容里可能嵌套调用其他脚本或二进制，比如
/etc/cron.weekly/man-db实际跑的是mandb -q，得打开看才知真实行为
真正麻烦的不是找不到配置，而是某处改了但没 reload、服务停了、或者脚本里用了相对路径导致 cron 环境下执行失败——查完四类位置后，一定顺手跑 systemctl status cron（Debian）或 systemctl status crond（RHEL），再翻 /var/log/syslog | grep CRON 确认最近有没有执行记录。
