Baeldung Pro – Linux – NPI EA (cat = Baeldung on Linux)
announcement - icon

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.

1. Overview

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.

2. Problem With Environment Variables

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.

2.1. Replicate the Problem

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.

2.2. Fix the Problem

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.

3. Check if Cron Is Running

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.

4. Check Script Permissions

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.

4.1. Redirect stderr in Crontab Job

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.

4.2. Fix the 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.

5. Conclusion

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.