The Complete Beginners Guide to Cron, Part 2
Welcome back to our beginners guide of the popular Unix tool, cron. If you missed part one where we introduced this tool, never fear, it’s right here.
We left off learning how to build a simple script to schedule automatic back ups. Now, we’ll learn how to set up our favorite type of notification: email.
Set email
So now you have backups being created, but you can’t be sure that the backup job is executing properly without actually logging on and checking. To address this, you can attach an email address to the crontab.
Open your crontab and add your email address to the top of the file:
You will now receive an email if your backup job fails. This feature will come in handy for our system status script that we’ll create in the next section.
Note: The email feature will only work if you have some sort of SMTP client configured on your server. If you don’t, it’s easy to install an MTA like Exim.
Receive basic system status updates – Use cron with scripts
Cron isn’t limited to just running commands directly from the crontab. We can also create scripts that perform complex tasks and then schedule those scripts.
In this example, we’ll be creating a simple script called system_status and emailing it’s output to our user each morning at 11am. We want this script to give us 2 basic pieces of information about the status of our system.
- Memory usage
- Disk usage
We’ll begin by creating a new file called system_status.sh. It does not matter where you put this (make sure it’s not web-accessible) so long as you know where it is. We’ll need the file path later.
vim system_status.sh
- We’re using vim, but any text editor will do fine. If you’d like a bit of help with basic vi/vim commands, check out this article.
Once your new file is open, copy and paste the following code into it. You don’t have to include the comments (#), those are just there for additional understanding.
# Uses the ‘free’ command to obtain the amount of system memory in use and turns it
# into a %. Doesn’t account for caching.
MEMS=$(free | grep Mem | awk ‘{print $3/$2 * 100.0}’)
# Uses the ‘date’ command to obtain the current date.
DAY=$(date ‘+%y-%m-%d’)
# Uses the ‘date’ command to obtain the time.
TIME=$(date +”%T”)
# Uses the ‘df’ command to obtain total drive space used.
USE=$(df –total -hl | grep total | awk ‘{ print $5 }’)
# Prints (or ‘echos’) the info we need using the assigned variables from above.
echo “${DAY} at ${TIME}: System Memory Use:${MEMS}% Disk Use:${USE}”
Save and close the file. Let’s make sure it’s executable by our user:
chmod 0700 system_status.sh
Test to make sure it’s working properly:
./system_status.sh
You should have received output similar to this:
17-05-11 at 10:18:16: System Memory Use:17.5217% Disk Use:35%
Kind of neat, right? You can alter the text to say anything that you like. Feel free to experiment and add degrees of complexity as you see fit. You can use that basic format to output a lot of info about your server.
Now we’ll add this script to our crontab and test to make sure it works by sending it’s output to a test file:
crontab -e
* * * * * /path/to/system_status.sh > test.txt
Save and close your crontab.
cat test.txt
As long as you received your script’s output, you can open your crontab and remove the test.txt redirect and add whatever schedule you’d like. The example below runs each morning at 11am.
0 11 * * * /path/to/system_status.sh
- Remember to add your email to your crontab
- Note that cron will not send you an email if the output of your script or command is directed elsewhere, such as our test.txt file.
Some users may point out that technically we could have included the entire script in a single line and added that to our crontab. That would have been a bit gangly, but admins string complex commands together into single lines (sometimes referred to as one-liners) quite often. The reason we didn’t in this instance was to demonstrate that it’s possible to run entire scripts from the crontab. That being said, as a best practice it is usually a good idea to run even simple commands from scripts. This takes slightly longer to set up, but it will help you avoid issues like having to escape particular characters and allows for easy management of jobs.
A note about monitoring…
The provided example is to demo some of the things that can be accomplished with cron and a bit of Shell scripting. For an actual production server, you’ll want to use one of the many great (and often free) monitoring tools that are already available. These include the popular Monit software, Cacti, and ‘sar’ command line tool. All of which will tell you most of what you need to know about your server’s status.
These are very basic examples of what you can accomplish with these tools. It should be fairly easy for you to expand on the concepts in this tutorial to create other, more useful scripts and cron jobs.
Thanks for checking this out! If you have any suggestions or question, drop them in the comments below. We’d love to hear from you.
