案例1：
crond服務異常或停止了。或是安裝服務后，忘記啟動服務。
操作系統 Red Hat Enterprise Linux Server release 6.6
# yum list cronie
# yum install cronie
安裝后，沒有啟動服務，然后作業就沒有執行。
# service crond status
crond is stopped
# service crond start
Starting crond: [ OK ]
案例2：
機房空調出現故障，導致IBM存儲因溫度過高，保護機制被啟用，然后linux在寫的過程，失去了這個節點，在存儲重起后，linux自動連接了存儲，但保留的原有的節點，導致文件被改為只讀。
然后crontab作業全部停止運行了。
案例3：
密碼過期后，導致crontab作業沒有運行，參考博客“Linux賬號密碼過期會導致crontab作業不能執行”。遇到這種情況，應該首先用chage -l user 查看賬號密碼策略，然后檢查日志信息
# chage -l root
Last password change : Apr 28, 2020
Password expires : Jun 27, 2020
Password inactive : never
Account expires : never
Minimum number of days between password change : 7
Maximum number of days between password change : 60
Number of days of warning before password expires : 7
一般/var/log/cron中會有類似下面這樣的信息
May 26 00:00:01 xxxx crond[26322]: (root) FAILED to authorize user with PAM (Module is unknown)
案例4：
注意配置，例如/etc/cron.deny是否禁止這個賬號運行一些crontab作業。還有就是檢查是否啟用了SELinux，檢查配置文件
# cat /etc/pam.d/crond
#
# The PAM configuration file for the cron daemon
#
#
# No PAM authentication called, auth modules not needed
account required pam_access.so
account include password-auth
session required pam_loginuid.so
session include password-auth
auth include password-auth
# cat /etc/pam.d/crond
#
# The PAM configuration file for the cron daemon
#
#
# No PAM authentication called, auth modules not needed
account required pam_access.so
account include password-auth
session required pam_loginuid.so
session include password-auth
auth include password-auth
有時候一些配置的變跟也會導致作業運行不能運行，個人僅僅碰到過一個簡單案例，通過重啟crond服務解決。很多復雜情況沒有遇到過，無法分析到位。不過一般解決的流程：檢查crond服務的日志，通過日志的報錯信息來判斷、定位分析問題。
/var/log/cron