Skip to main content

Creating a Cronjob to Run a Script Periodically

Hands-On Lab

 

Photo of

Training Architect

Length

00:15:00

Difficulty

Intermediate

Using cron jobs allow us to run processes according to a recurring schedule. We can set them to run at set times at regular intervals, to perform functions like backups, send emails, or most anything else we might want to do, which can be very useful for a System Administrator

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

Creating a Cronjob to Run a Script Periodically

Introduction

cron jobs allow us to run processes according to a schedule. We can set them to run at set times at regular intervals, to perform functions like backups, send emails, or most anything else we might want to do.

The Scenario

The administrators are concerned about the load on the system impacting application performance during the work week (Monday through Friday). They want us to create a script that will gather the time and system load information, and then configure cron execute it once per minute between 8 AM and 5 PM. Once we've gotten it done, we'll need to verify that the script's output is going to the the correct log file, /var/log/loadavg.log.

Logging In

Use the credentials provided on the hands-on lab overview page, and log in as cloud_user. We'll need to be root right away, so let's run sudo -i as soon as we get in, then we can continue.

Verify That the crond Service Is Enabled and Running

Ensure that crond.service is active and enabled:

systemctl status crond.service

If we see an active (running) status, then everything is good to go.

Verify that /usr/local/bin/loadavg.sh is Executable for All and Produces Correct Output

Check the permissions on the /usr/local/bin/loadavg.sh file:

ls -l /usr/local/bin/loadavg.sh

It's not executable, so let's fix that:

chmod a+x /usr/local/bin/loadavg.sh

This script is going to run uptime | tr ',' ' ' | tr -s ' ' | cut -d' ' -f2,10,11,12, which is the uptime of the system and the load average. Let's try running it:

/usr/local/bin/loadavg.sh

The script is also supposed to have sent that data to /var/log/loadavg.log. Let's see if it did:

cat /var/log/loadavg.log

We should see a timestamp and the three load averages in there.

Create a cron Job that Executes /usr/local/bin/loadavg.sh Once per Minute During the Hours of 8AM-5PM on Monday through Friday

Set the EDITOR variable (run export EDITOR=nano or export EDITOR=emacs to change the default editor to Nano or EMacs, respectively), if desired, and use crontab -e command to create the following content:

# Min   Hour    DoM     Month     DoW     Command
   *    8-17     *        *       1-5     /usr/local/bin/loadavg.sh

Note that anyone setting this up on a Saturday or Sunday (or outside the hours of 8AM and 5PM) will not see it run. We'd have to change the 1-5 up to catch either of those two days (Saturday being 6 and Sunday being 0 or 7), or we'd have to use different hours.

Now we can save the cronjob. To check our work, we can run crontab -l, and list out the contents of our crontab file.

Verify Cronjob is Running and Producing Correct Output

If we want to know whether our job is running or not, we can run tail /var/log/cron after a few minutes, and we should see entries in there for our loadavg.sh script. We should also take a look at the log that the script is writing to, with:

cat /var/log/loadavg.log

If the job is running, then we'll see contents like we did when we ran the script manually, once a minute.

Conclusion

We've done it. Our administrators can take a look at that log file after a few days, and maybe start nailing down what's happening on the server that causes it to slow down. Congratulations!