crontab -l 看不到任务但脚本在运行，大概率是 anacron 或 systemd timer 在执行；anacron 通过 /etc/anacrontab 和 /var/spool/anacron/ 时间戳运行，不依赖 cron；systemd timer 则用 systemctl list-timers 等命令管理，与 crontab 完全无关。
crontab -l 看不到任务，但脚本却在跑 —— 先确认是不是 anacron 在干活
很多用户执行 crontab -l 返回空，却看到日志里有定时任务在运行，第一反应是“cron 被黑了”或“配置丢了”，其实大概率是 anacron 在后台默默执行。anacron 不依赖 cron daemon，也不读取用户 crontab，它靠自己的配置文件和时间戳判断是否该补跑任务。
检查方法很简单：
- 运行
ls /etc/anacrontab，如果存在，说明系统启用了 anacron - 查看
systemctl status anacron，确认服务是否 active - 翻看
/var/spool/anacron/下的时间戳文件（如cron.daily），里面记录了上次执行时间 - anacron 的任务定义在
/etc/anacrontab，格式和 cron 不同：字段是周期 延迟 任务名 命令，没有分钟/小时等精细字段
systemd timer 显示启用但没进 crontab —— 它压根不走 cron 路径
systemd timer 是完全独立于 cron 的调度机制，crontab -l 当然查不到。它的触发、状态、日志都得用 systemd 工具链查。
快速定位：
- 列出所有启用的 timer：
systemctl list-timers --all（注意加--all才能看到 inactive 但已 enable 的） - 查某个 timer 的定义：
systemctl cat和timer_name.timersystemctl cattimer_name.service - 看最近执行日志：
journalctl -utimer_name.service --since "2 days ago" - 常见陷阱：timer 文件里写了
OnCalendar=，但对应 .service 文件没写Type=oneshot或漏了ExecStart=，会导致看似启用实则不执行
为什么 anacron 和 systemd timer 会“偷偷”跑你的脚本？
它们不是凭空出现的——绝大多数来自系统包预置或管理员手动部署。比如：
-
logrotate、apt-daily、mandb这类维护任务，在 Debian/Ubuntu 上默认由 systemd timer 驱动；RHEL/CentOS 则倾向用 anacron - 某些软件安装时会自动 drop 一个
.timer文件到/lib/systemd/system/并systemctl enable，你根本没手动操作过 - anacron 的
/etc/anacrontab可能被发行版模板写死，比如包含1 5 cron.daily nice run-parts /etc/cron.daily，而你只改了/etc/cron.daily/myjob，就以为是 cron 在跑 - 兼容性注意：anacron 不支持秒级或高频调度；systemd timer 的
OnBootSec=在容器或 WSL 里可能失效，因为 boot 概念模糊
排查时最容易忽略的三个点
不是命令没输对，而是这几个地方卡住太多人：
- 别只查 root 的
crontab -l，也试试sudo -u www-data crontab -l或其他服务账户——有些脚本是用特定用户身份注册的 timer 或 anacron 任务 -
systemctl list-timers默认只显示 loaded + enabled 的 timer，但如果你删过 unit 文件又 reload 过 daemon，旧 timer 可能还残留在/run/systemd/transient/里，用systemctl list-timers --all --state=loaded更准 - anacron 的执行日志通常不在
/var/log/syslog，而是在/var/log/syslog或/var/log/messages里搜anacron:，但更可靠的是直接看journalctl -t anacron
真正麻烦的从来不是“谁在跑”，而是“谁注册了它、在哪改、改完会不会被包管理器覆盖”。尤其当多个机制共存时，得一层层剥开看，不能只盯着 crontab -l 那一行空输出。
