Here's the latest in our new series on OS tips from power users: a seemingly trivial task. You have a computer, most likely a laptop, that you wish to keep suspended while you're not working. For example, let's say overnight. At the same time, you wish to run a handful of maintenance tasks, like backups and cleanup, which you don't normally do during the day. So you need a mechanism that will send your machine to sleep, wake it up when necessary, run cron jobs, then send it back to sleep again.

This is a beginner tutorial on using crontabs or cron jobs in your LAMP (Linux/Apache/MySQL and PHP) web hosting account. Crontabs can be used to automatically execute server side commands, such as a PHP script, at periodic intervals. You can specify these periodic intervals, whether you want the script to be executed hourly, daily, weekly, and so on.

Like most Linux commands, there are any number of explanations for the name "crontab" -- the one I prefer is c(h)ronological table. To begin using it, type crontab -e to invoke a text editor on the file. By default crontab -e uses vi. To change the default editor to, say, pico, add to your .profile the line:

export VISUAL=pico

One of the issues that has long irritated Unix users when setting up cron jobs is how to set up a job to run on the last day of the month. Unless one wants to set up a separate cron job for every month (and this still leaves the problem of leap years), it isn't at all straightforward how to attack this seemingly ordinary problem with an ordinary solution. However, there are some reliable ways to code around the problem. One long winded but workable way to determine the last day of any month in any year is to string together some well known Unix commands. The last day in the month of February next year, for example, could be extracted from the last non-blank line in the output of the calender command like this:

But hcron also addresses a few problems cron didn't anticipate, leaving aside its arcane syntax. When you run a cron job, you must kludge together something in the job itself or in the command you pass to cron to send an email when a job is completed. The hcron utility is expressly designed to allow for an email when the job is run.

The real kicker is remote execution. When cron was conceived, the computing environment was much less complicated -- and less networked. Today, it's hard to imagine any professional IT worker not having to manage remote machines. Hcron is designed for remote execution as well as local.

Are you looking for a solution to backup your data to a remote location? While a solid backup solution such as Arkeia or TSM from IBM are nice from an enterprise point of view, simpler solutions are available from a home user's perspective. I will walk you through on you how you can backup your data to a remote server, using the default tools available on all linux systems. In a nutshell, we will use ssh capabilities to allow a cron job to transfer a tarball from you local machine to a remote machine.

You can execute crontab if your name appears in the file /usr/lib/cron/cron.allow. If that file does not exist, you can use crontab if your name does not appear in the file /usr/lib/cron/cron.deny.

If only cron.deny exists and is empty, all users can use crontab. If neither file exists, only the root user can use crontab. The allow/deny files consist of one user name per line.

Most distributions take advantage of that fact to schedule recurring maintenance jobs to be run while you're least likely to be around. Things like trimming system log files, for example. Otherwise they might eventually fill every byte of available disk space. That's where cron and crontab come in, and that's our topic for the week.

Cron is a tool that functions based on a specific Linux user. In fact, every user on a server can have individual cron settings.

Therefore, whoever you are logged in as will be the one whose cron settings you create. If you must create a cron setting that root user initiates, you should be logged in as root.

The command to create/edit, list, and remove cron jobs is crontab. If you call it with the -u option, it specifies the name of the user whose crontab is to be tweaked. If this option is not given, crontab examines "your" crontab, i.e., the crontab of the person executing the command. If you are looged in as root and run crontab without -u, then root's crontab is listed/modified/removed.