Article by Jerry Low
Geek dad, SEO data junkie, investor, and founder of Web Hosting Secret Revealed. Jerry has been building Internet assets and making money online since 2004. He loves mindless doodling and trying new food.
Web hosting is designed to be easy, straightforward, and perfect for the professional who’s on the go and simply cannot dedicate every hour of every day to managing their server software and associated tasks. To that end, almost every server based on Unix or Linux offers an automated task manager known as the "Cron Job" or "Crontab." This software utility is much like the task scheduler in Microsoft Windows, in that it can be told to do certain things at certain times, saving a user from performing these tasks manually. This is especially important when one considers that many routine server maintenance, backup, and communications procedures can take hours and hours to complete. Most people simply want to go home after a day in the office and relax, rather than spend their evening backing up files and managing contacts.
Those people are in luck, as every task can be scheduled on a daily, weekly, or monthly basis — or even further apart, in some cases, and specific instructions can be given to the server within the Crontab utility on how to perform the task, how to know when it’s complete, and what to do when the task at hand has actually been finished. Users will be able to relax while their server does all of the heavy lifting for hours; or they can simply schedule the work to be completed while they’re hard at work in their own offices. Because it’s automated, a Cron job can occur at virtually any hour of the day.
A Cron job isn’t exactly an easy thing to master; in fact, it’s widely considered one of the most advanced configurations available on a standard Linux or Unix web server. This is partially because the language used to program these jobs is so archaic and, in some cases, completely backwards. When it comes to telling a certain time to the Cron job or Cron tab in question, things are certainly backwards, upside down, and a little confusing.
The format for telling time via a Cron job is such:
MINUTE HOUR DAY-OF-MONTH MONTH DAY-OF-WEEK COMMAND
It’s all one line, and even number and command is side-by-side in one uniform contraction. It’s enough to make most developers and server operators wince and, in fact, many of them do until they get a hang for developing an efficient Cron job. It’s important to note that every aspect of the Cron job’s time is numerical; there are no month names day names, or other words used throughout the development of the time during which a task should be performed.
Therefore, let’s set a Cron job up for 10:30 a.m. on July 7th in order to get a feel for how a Cron job’s time looks when it’s turned into strictly numbers.
30 10 07 07 *
The example above states that the job should be completed at the 30th minute of the tenth hour on the seventh day of the seventh month. All numbers are two digits long, even when the month or day is only a single digit. This is important to remember, as a single digit will often cause the Cron job to be invalid and it simply will not be performed, ever. At the end of the con structure, an asterisk indicates that the job should be performed on any day of the week. This is important, as setting it to 03 for Wednesday would mean that the task would only be performed on July 7th if that day was a Tuesday. That’s likely to happen once every seven or eight years, which is a little absorb for most developers to consider.
Another important consideration to make when setting up a Cron job is that the hour format is 24-hour military time rather than 12-hour civilian time. To change the time of Cron job to 10 p.m., the hour would be changed to 22 instead of the current 10.
Finally, if a user merely wants to complete a task on a daily, monthly, or even yearly basis, they can skip the process of setting a specific time entirely. Instead, the Cron job process provides for simply using variables which determine when a job is done on these frequent intervals. These include:
Because the time cannot be strictly controlled and determined using hours and minutes, these jobs will happen at exactly midnight, according to the server’s internal time, at the interval requested. That means that the @monthly interval will occur at exactly midnight on the first day of every month. The @yearly interval will occur at exactly midnight on the first day of every year; and the @daily interval will occur at exactly midnight every single day of the year.
This is far easier than setting a specific date, time, and day of the week, but certain tasks being performed at midnight on the first day of the month or year may have some drawbacks for certain customers. Always keep the needs of both administrators and site visitors in mind when scheduling tasks that occur at exactly midnight.
As can be seen in the example above, constructing an actual Cron job is relatively easy. The date must be first defined and then the function of the Cron job is immediately defined afterward. That function can be literally anything, including running a PHP script or running a customized backup script that stores the server’s files and data in either a remote or local file. For clarification, we’ll build on the example that was previously used and instruct the Cron job to run a PHP script on July 7th at 10:30 in the morning. This PHP script will be called "backup.php" and we’ll assume that the PHP file is a full backup script that gathers, compresses, and stores site files on the seventh of the month when instructed to do so by the server. Here is what it looks like:
30 10 07 07 * http://your-domain-name.com/backup-scripts/backup.php
When this Cron job is entered into the list of the server’s Cron tabs, it will be automatically executed at 10:30 a.m. every July 7th of every year. It will run the PHP backup script that is located in the "backup-scripts" directory, and that’s where the true genius of the Cron job setup works.
Instead of requiring advanced commands of its users to perform things like site backups and cache flushes, it simply gives users the ability to execute existing scripts at a specified interval or on a specific date at a specific time. This means no advanced programming knowledge is needed beyond what the user already knows. PHP is perfectly capable of backup site files, as are much more advanced files and programming languages that the more sophisticated user might develop for their Linux server.
This simple setup can be used to do virtually anything, then, so long as a pre-written script provides for the execution of those actions independent of user input. This does mean that any script executed by a Cron job within a Cron tab must be fully automated and able to perform on its own, however. For example, it would be impossible (and simply illogical) to tell the Cron job to execute a WordPress index or theme file every day at the same time. There are simply no actions or automated processes defined and, while the Cron job would certainly execute the file, it would do nothing and would sit static until user input was provided in another way.
For this reason, if coding or downloading backup scripts or others to work with Cron jobs, always make sure that they require exactly zero user input to perform their functions successfully. An automated task scheduler must be paired with an automated process within the file it executes. There are no exceptions to this rule.
Every specific Cron job which is specified for execution lies within a larger file which is known as a Cron tab. Some servers have multiple Cron tabs for multiple types of applications and automated inputs, but this is rare and largely reserved for the most advance server operators and owners. Those who have just one Cron tab file can use the commands below to edit, delete, or view the file in its entirety, with each of their specific automated tasks listed for viewing within the file.
This command removes (thus "r") or deletes the entire Cron tab file itself. This will effectively purge it of all commands and automated scripts, and restore it to a blank file that can be rebuilt. This is a suitable option for those who have managed to corrupt the file or somehow misappropriate tasks and times. Sometimes, it’s simply easier to start all over.
In this case, "e" stands for "edit." Those users who want to edit the functions described in a Cron tab rather than delete the file entirely can use this command to be taken to the command-line editor which will allow them to add new tasks, remove old ones, or change the applicable schedule times for each of the Cron jobs listed within the Cron tab document.
In this case, it’s easy enough to remember by associating the "L" with "look. This command allows a server administrator to simply view the full contents of their Cron tab file without removing it from the server entirely and without having the ability to edit the contents. This read-only display of Cron tab content is perfect for remembering which tasks are scheduled for which times, and for verifying the integrity of the file itself.
Generally speaking, the only thing automated about a server is the spinning of its hard disk and the performance of its hardware features. Beyond that, though, the server must the trained and instructed to do routine and extraordinary tasks that go above and beyond merely displaying a software control panel or upgrading the installation of PHP or Perl that a user has placed on the hard disk.
It’s important to remember that one of the most essential functions a server can execute on a regular basis is the creation of a site backup of data and settings. There is virtually no way to automate this process without a Cron job and, due to the nature of the internet and all of the malicious visitors which pass through a site daily, failure to automate this process on a daily or weekly basis could result in significant and catastrophic data loss.
Above and beyond that, though, there are a number of tasks that should be automated using the Cron job process. These tasks include purging any site caches which might display outdated images or printed content to site visitors; it also includes deleting old files, cleaning up old directories and images, and making sure that everything stored on a server’s hard disk drive is current and uncorrupted.
Just like a healthy personal computer automatically schedules disk maintenance, antivirus and malware scans, software updates, and file deletions, a healthy server must be configured to take care of itself and remain in good standing. Otherwise, it becomes vulnerable to crashes, hacking attempts, and data loss that will lead to lost profits, advertising, content creation, and even search engine ranking status.
Creating a Cron job within a standard Cron tab is one of the easiest things a server administrator can do. The process lies within the standard command line and breaks down every segment of time into a two-digit code. Because it requires no additional knowledge of any new programming language in order to automate tasks, the service essentially builds on the existing programming and server operations knowledge that an administrator already possesses. With this being the case, there is simply no reason not to begin automating essential server functions and ensuring the integrity of site data and operations.
For further reference and more code samples, do check out Robert’s previous post: How to save time with cron: Basic guide and sample codes as well as visiting this site: Live Cron Jobs.