The exciting list of Cron oddities

Here follows a list of reasons why maybe you should think about using a proper job scheduler whenever you touch an existing cron job, or create a new one:

Cron doesn’t tell you if it fails to run. Cron doesn’t tell you if the thing it ran, failed to run. Cron likes to log to syslog, except nothing there is remotely interesting. Cron instead will cry that you don’t have an MTA (email) configured on your server. Cron will then just cry and cry and never show you any logs. Cron will email you if you do have an MTA configured on your server. Cron will probably be very chatty so you’ll likely configure your MTA to actually store emails locally. Cron emails will therefore likely never be read, and accumulate in root’s inbox. Why are we even talking about emails we just want to read jobs’ logs what the fuck cron. Cron will ignore any PATH you have setup unless you specifically set it in a place it decides it will accept. Cron will ignore and refuse to run all your properly configured jobs even if just one of them is misconfigured. Cron has no native way to validate a cronfile without any side effects or actually trying to run it, because it wants to assert its dominance over human life forms. Cron likes being told to run at times that make no sense to a human (and so these things exist) Cron has no concept of anything under a minute. Cron will helpfully replace your % (percent character) with newlines and send everything after it as STDIN because obviously that’s what you meant. Cron will outright refuse to run if it doesn’t end in a newline probably because POSIX, like that is ever a good explanation for anything. Cron will let you setup an /etc/crontab file and run it but also let you see per-user crontab’s with crontab -l . (check /var/spool/cron/crontabs for all of them).

Don’t assume Cron will run with: