crontab -l可查看当前用户定时任务，空输出表示无任务；系统级任务需单独检查/etc/crontab、/etc/cron.d/及/etc/cron.*目录。
如何查看当前用户的crontab定时作业
直接运行 crontab -l 就能列出当前登录用户自己的所有定时任务。如果没设置过，会提示 no crontab for xxx；如果权限不足（比如普通用户试图看 root 的），会报错 must be privileged to use -u。
常见误区是以为 crontab -l 能看到系统级任务——它不能。系统级任务（如 /etc/crontab 或 /etc/cron.d/ 下的文件）需要单独检查。
- 想看其他用户的？需 root 权限：
sudo crontab -u username -l - 输出为空但怀疑有任务？确认是否真没添加，或是否误用了
crontab -e但没保存退出 - 注意：某些发行版（如 CentOS Stream 9+）默认禁用用户 crontab，需确保
crond服务运行且/var/spool/cron/目录可读
如何查看系统级crontab文件和cron.d目录
系统级定时任务分散在几个固定位置：/etc/crontab、/etc/cron.d/ 目录下的所有文件、以及 /etc/cron.hourly、/etc/cron.daily 等目录里的脚本（这些由 run-parts 触发，不直接写在 crontab 格式里）。
执行以下命令可一次性汇总查看：
cat /etc/crontab 2>/dev/null
ls /etc/cron.d/ 2>/dev/null | xargs -I{} sh -c 'echo "--- /etc/cron.d/{} ---"; cat /etc/cron.d/{} 2>/dev/null'注意：/etc/cron.d/ 下的文件格式和 /etc/crontab 一致，但**必须显式指定用户名字段**（如 * * * * * root /path/to/script），漏掉会导致任务被忽略且无报错。
-
/etc/cron.d/中的文件名不能含点（.）或破折号（-），否则 run-parts 会跳过（例如backup.sh可行，backup-v2不行） -
/etc/cron.hourly等目录里的脚本必须有可执行权限（chmod +x），否则 cron 会静默跳过 - 某些容器环境（如 Alpine）默认不带
run-parts，这类目录实际不生效
如何确认 cron 服务是否运行并实时加载了新任务
即使改了 crontab 或系统配置，若 crond 没运行或没重载，任务也不会执行。先检查服务状态：systemctl status cron（Debian/Ubuntu）或 systemctl status crond（RHEL/CentOS）。
修改 /etc/crontab 或 /etc/cron.d/ 后无需手动重载——cron 进程会每分钟扫描这些路径；但修改用户 crontab（crontab -e）后自动生效，无需干预。
- 如果刚加了任务却没执行，用
journalctl -u cron -n 50 --since "1 hour ago"查看最近日志，重点关注(CRON) INFO (Running @reboot jobs)或error: bad username类错误 - 测试任务是否触发：临时写一条
* * * * * root echo "$(date)" >> /tmp/cron-test.log 2>&1到/etc/cron.d/test，等一分钟看文件是否生成 - 注意时区：系统 cron 默认用系统本地时区，但 Docker 容器可能用 UTC，导致时间错位
为什么 ps aux | grep cron 看不到所有定时作业
ps 只显示正在运行的进程，而 cron 本身只是一个守护进程（crond），它不长期运行任务，只是按计划 fork 出子进程执行命令。所以 ps 永远看不到“定时作业”，只能看到 crond 自身。
真正要定位某个任务是否在跑，得结合日志和进程树：pgrep -f "your_script_name" 或查 /var/log/syslog（Debian）或 /var/log/cron（RHEL）中 cron 的执行记录。
- 有些任务执行极快（如
touch /tmp/flag），ps 抓不到，但日志里会有痕迹 - systemd timer（如
systemctl list-timers --all）是另一套机制，和 cron 无关，别混淆 - 第三方调度工具（如 Jenkins、Airflow）的任务完全不在 cron 体系内，需各自管理界面或 API 查询
实际排查时，最易被忽略的是：不同用户 crontab 与系统级配置的执行上下文差异（PATH、HOME、shell 环境），同一行命令在 crontab -e 里能跑，在 /etc/cron.d/ 里可能因缺 PATH 失败。
