Learn through the super-clean Baeldung Pro experience:
>> Membership and Baeldung Pro.
No ads, dark-mode and 6 months free of IntelliJ Idea Ultimate to start with.
Last updated: December 21, 2024
Cron is a utility in Linux that allows us to run various tasks at specified time intervals. These tasks are listed in a file called crontab.
Often, there are problems with getting the tasks executed correctly.
In this tutorial, we’ll look at how to fix the most common crontab issues.
First, we’ll discuss how to add the environment variables in crontab. After that, we’ll learn how to restart cron if it’s not running on a system. Then, we’ll learn how to redirect stderr of a cron job to a log file. Finally, we’ll study how to set the script’s permissions for crontab.
Cron passes a minimal set of environment variables to run its jobs. Therefore, the cron jobs often lack required variables unless specified explicitly in the crontab.
Let’s replicate the problem with the cron environment variables access.
First, we run the env command on our terminal to see all the variables in our environment:
$ env
SHELL=/bin/bash
SESSION_MANAGER=local/ws-310:@/tmp/.ICE-unix/3035,unix/ws-310:/tmp/.ICE-unix/3035
QT_ACCESSIBILITY=1
COLORTERM=truecolor
...
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
LC_NUMERIC=be_BY.UTF-8
_=/usr/bin/env
Here we can see a long list of all environment variables used.
Then, let’s repeat the same command in the crontab. For that, we use the crontab -e command:
$ crontab -e
Let’s add the env command to the crontab:
* * * * * env > /tmp/env.output
Now, we check the tmp/env.output file:
$ cat /tmp/env.output
HOME=/home/user
LOGNAME=user
...
SHELL=/bin/sh
PWD=/home/user
We can see that most variables from the above are missing.
The missing environment variables may be the reason for the script not running correctly via crontab.
To fix it, let’s put the environment variable at the top of the script:
#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# The rest of the script follows
As can be seen, we’ve placed the PATH variable at the top of the Bash script below the shebang #!/bin/bash.
In the same way, we can add any environment variable if the script misses it.
Now, let’s check the /tmp/output file:
$ cat /tmp/env.output
HOME=/home/user
LOGNAME=user
...
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/home/user
As can be seen, the PATH variable has now been added to the cron job environment space.
Another common issue is that the cron daemon isn’t running.
Let’s use the pgrep command to check if the cron daemon is alive:
$ pgrep cron
If we see no output, then it means that the cron isn’t running.
Therefore, we need to start the daemon with the systemctl command with the sudo access:
$ sudo systemctl start cron
Now, the cron service should be running on our device. Let’s check it again:
$ pgrep cron
1405
We can now see the number 1405 which is a cron PID number. It means that the cron daemon is running correctly.
Often, a script that is run by the cron lacks executable permissions and doesn’t start correctly.
To fix this problem, we’ll first look at how to redirect stderr to a script in crontab.
Then, we’ll learn the command to fix the permissions issue.
Crontab scripts often lack information about an error.
For example, let’s look at the following crontab command:
* * * * * /path/to/script >> /tmp/output
Here, we run the script every minute and redirect its output to the /tmp/output file.
If the script isn’t working, its stderr logs aren’t provided to the output file.
To get the error logs to the output file, we need to redirect stderr from the script by adding 2>&1 at the end of the line:
* * * * * /path/to/script >> /tmp/output 2>&1
As a result, any script error is redirected to the /tmp/output file.
Now that we know how to gather the most useful logs from the crontab scripts, let’s dig into the problem of script permissions.
Often, a script that is run by the cron lacks executable permissions and doesn’t start correctly.
For example, let’s look at the crontab task:
* * * * * /path/to/script >> /tmp/output 2>&1
Here, we may see the error in the /tmp/output file:
bash: /path/to/script: Permission denied
In this case, we need to make sure that the /path/to/script file is executable.
For that, let’s use the chmod command:
$ chmod +x /path/to/script
Now, if we check the script’s permissions with the ls -l command, we should see the following:
$ ls -l /path/to/script
-rwxrwxr-x 1 user user 20 Dec 11 13:24 script
As expected, the symbol x now appears for the script file which means that it’s now executable and should no longer cause the crontab errors.
In this article, we’ve learned how to fix a script that isn’t working with crontab.
First, we focused on adding environment variables to the crontab. Then, we learned how to check if the cron daemon is sunning. After that, we studied how to redirect stderr to a log file. Finally, we updated the permissions of the script to make it executable.