cron can be a real S.O.B. to setup if you’ve never scheduled a job before. The utility is downright nitpicky at times. Not to fear. If your cron job is not running, here are the top 6 most common hang ups you might be snagging on.
1.) Wrong environment
Your user account operates under a specific environment where you have a direct path to the programs and utilities you need. cron operates under a limited path and does not always have access to the same programs. Your PATH is one such environment variable that tells the shell where to look for executable programs. If you’re trying to use a program that isn’t in your path, the shell will return error. In the case of cron, your job will simply not run.
You can see if this is the case by comparing the cron environment to your user environment. Plug this small line of text into your crontab and take note of cron’s output in /tmp/path.txt
Compare the contents of path.txt with your current environment and you will see a big difference in where cron searches for executables. Run the following command to see your current path.
Solution – There are two things you can do in this case. The first involves using absolute paths in your script. This ensures cron has a complete path to the program you’re running:
Alternatively, you can set your path at the top of your script like so:
This will give cron direct access to your program. Either way, you should be good to go.
2.) Your scripts aren’t owned by root
From the man page:
If you’re placing scripts inside one of the /etc/cron.* directories, the scripts must be owned by root. If root does not own the script then cron will simply skip over it entirely. Many users choose to place scripts inside of these folders to bypass the finicky requirements of their own crontab. Rightly so, but even here you will find cron to be relentless with it’s requirements. Make sure your scripts are owned by root so things go smoothly.
3.) Your script names aren’t formatted properly
From the man page:
Once again, we see cron putting his foot down until the people around him fall in line with his unique perspective on reality. Your script cannot contain any special characters when placed into one of the /etc/cron.* directories. A common practice is appending your script with the .sh file extension. This is a no-no for cron. As you know, Linux does not require a file extension and your script will run just fine without one. Do what cron says and you will be a happy admin.
4.) Your cron script is not executable
An obvious one to some. Not so obvious to others. Your cron script must have executable permissions in order for cron to run it. Use the following command to make your script executable if it isn’t.
Executable scripts make cron very happy.
5.) Incorrect permissions
Permissions are a very common problem especially for commands placed in crontab. crontab runs under the permissions of the crontab user. If you don’t have proper permissions under your user, cron is not going to have the proper permissions either. Always run your script or command prior to scheduling them with cron. If your commands don’t run or error out with access denied errors, you know you need to make adjustments. If your script or command absolutely requires root permissions, then create a crontab as the root user of your system.
6.) cron daemon not running
The last and most insidious reason why cron is not working. I’ve racked my brain for hours trying to figure out why a cron script wasn’t working only to find out the daemon itself wasn’t even running. You can verify whether or not cron is running in a number of ways.
cron is running if you see a number. cron is not running if you don’t.
Easy way on Debian systems to check the status of cron.
These are 6 of the most common reasons why your cron jobs are not running. Run through this list next time cron refuses to do what you tell him to. Eventually, cron will start to see things your way and will do as he’s told.