So, your cronjob did not run?
Posted by Steve on Thu 21 Feb 2013 at 09:26
Recently I was hit be a problem which was ultimately caused by a failure to run a cron-job. Here I'm going to document the three most common means for failure that I know about, in the hopes of avoiding them in the future.
We've briefly discussed cronjobs in the past.
In brief there are two different ways to schedule jobs on Debian systems:
- In your personal crontab file, viable with "crontab -l" and editable with "crontab -e".
- Via a system file.
The system files have the most failure cases. Generally speaking you will find directories such as the following, are each invoked from /etc/crontab:
/etc/cron.daily /etc/cron.weekly /etc/cron.monthly
The contents of these directories are executed via the run-parts tool, which is designed to run every executable in the named directory in turn.
Because the contents of, for example, /etc/cron.daily are executed via run-parts your scripts must have suitable filenames.
As this demo shows run-parts will skip some files:$ mkdir /tmp/x $ ln -s /bin/ls /tmp/x/foo.bar $ run-parts /tmp/x $
Here the (horrid) name "foo.bar" has been skipped by run-parts. You can see by reading "man run-parts" which filenames are going to be executed.
This problem only affects the system cron entries, because they are the only ones executed by run-parts.
A common cause with broken personal cron entries is that the crontab file doesn't contain a newline at the end of lines.
If you were to add an entry to /etc/cron.d to define a system cronjob which executes with an arbitrary frequency you must be careful with permissions.
You must ensure that the file has permissions 0644, otherwise the script will not run and you'll be puzzled by this mysterious error in syslog:(*system*foo) WRONG INODE INFO (/etc/cron.d/foo)
Fixing this should be as simple as running "chmod 644 /path/to/file", but some older versions of cron will ignore such updates. Instead you must rename your cron file.
Note: If you wish to remove group/other read-permissions that is fine. The important thing here is that the file must not be group/other writable. (For example a snippet owned by root:root, with permissions 664 would be ignored, even though only root may write to it.)
Hopefully this quick reference was useful, but if there are other common "gotchas" I'd love to hear about them!