Use of 'at'

'at' is a program to carry out commands that you intend to do only once. It's mostly used for scheduling specific jobs under specific circumstances. If you had to rotate your company's webserver logs every Saturday, 'at' is not the appropriate tool for the job. That would be done best with 'cron', about which we will talk about shortly. Let say your boss, the CTO, called for a meeting with you at 1:00. He wants to know how frequently your external consultants are logging into the network. This is a prime candidate for 'at'.

First, you'd type:

at 12:45

which would give you plenty of time to get that information before the meeting. You will see the 'at' prompt:

warning: commands will be executed using /bin/sh
at >

Now you'd write the commands you want carried out. Here we'll get the output of the command last, which tells us who's logged in to our servers lately, and write it to a file called 'log-ins'. The second command, separated by a semi-colon (;) will then print that file using lp.

last > $HOME/log-ins; lp $HOME/log-ins

press 'Enter' and then 'Ctl + d' and you will see the following:

job 15 at 2003-02-16 12:45

Of course, your job number will vary with the number of times you've used 'at'.

There are various ways to indicate at what time you want 'at' to carry out commands. at now + 5 minutes will carry out a command five minutes from when you type it. There's even a provision for at teatime which will carry out commands at 4:00 PM/16:00 hrs. (If you don't believe me, consult 'man at'!). You can cancel these jobs as well. If you type:

atrm 15

you will remove job 15 from the 'at' queue. To see what is in the 'at' queue, type:

atq

You can control which users are allowed to use 'at'. By default

/etc/at.deny

/etc/at.allow

/etc/at.deny

Therefore, anyone who is not in at.allow cannot use 'at'. The question of using one file or another comes down to a question of your management style. If you prefer to let people use things until they abuse the privilege, then use the default at.deny. When the user 'barney' programs an 'at' job to set off an infernal sounding noise when he's gone to get coffee, scaring the bejeebers out of everybody in the office, then you can add him to the at.deny file. If you're of the opinion that nobody needs to use it, then create an at.allow file with only your personal user account listed. Remember that the root user can always use at.

Use of 'cron'

From a system administrator's point of view, the cron daemon is probably the best thing since sliced bread. You can schedule practically any program [1] at any time, for any date and at any interval. That is to say, if you want a text dump of the number of times a person with the IP address 64.09.200.12 has logged into your computer and you only want it on February 4th, cron will do this for you.

The jobs that you want to run with cron can be scheduled in various ways. The most common way is to edit a file which is known as your crontab. Normally, each user has his/her own and is able to schedule jobs by editing it. You can add to and delete entries from you crontab by typing:

crontab -e

But before we go jumping right into scheduling jobs, it's important to point out that cron looks for a particular syntax in your crontab file. You just can't just write:

get my mail from mail.mydomain.com

and expect it to work. The syntax in your crontab is not easy to master, but it is not excessively difficult to comprehend either. First, there are 5 time periods that cron looks for. You start your crontab entry with these. Here is the order and some examples:

You will not be able to use all of them at the same time. If you have used the first four, you do not need the last one. This last one, the weekday, is particularly useful because it lets you run jobs once a week. There is also another way of doing that and we'll talk about it shortly. If you don't wish to specify a particular time period, you must substitute an asterisk (*).

Once you have decided when you want a particular command to be run, you add the command itself at the end. Thus, a typical crontab entry will end up looking like this:

30 3 * * 0 $HOME/bkup_script

which runs a script in your home directory to back up your files at 3:30 AM on Sunday. If you entered this into your crontab, you would simply save the file by pressing ESC + :wq which is a vi command. Vi is normally the editor that crontab uses by default, but you may use a text editor other than vi, by typing export VISUAL=pico, for example, which would allow you to use the pico editor. Every time you want to alter, add or delete an entry, you would first type

crontab -e

Enter whatever it is that you want to get done and then type

ESC + :wq

crontab -l

If you want to delete your crontab file, type

crontab  -r

Variations on a theme

Crontab entries don't have to necessarily have just numbers in them. We can combine the numbers with other characters to modify how commands get carried out. For example, I have a USB webcam that doesn't really do what it's supposed to, which is to take a picture every minute and then shut off. It takes the picture all right, but it doesn't shut off. So I wrote a script to shut it off and then I added a crontab entry to call this script every minute. This is what I added:

0-59/1 * * * *  $HOME/shutoff_cam >/dev/null 2>&1

Let's look at this one part at a time

0-59/1

basically means that between the 0-59 minutes of every hour, at every 1 minute interval, the camera is to shut off. To show you how useful cron is, I remember seeing a James Bond movie where the perpetual bad-guy, Blofeld, was brainwashing girls to carry out biological attacks from a base in the Swiss Alps. He would play these hypnotic tapes to the girls every evening. There is one scene where you see Blofeld and one of his minions switching the tapes manually. If only they had had a Linux computer! They could have done this:

30-45/3 22 * * *  mpg123 /home/esblofeld/brainwash_girls.mp3 >/dev/null 2>&1

which would play the brain-washing instructions at 3 minute intervals between 10:30 and 10:45 PM.

Disclaimer: PLEASE DO NOT TRY BRAINWASHING TECHNIQUES AT HOME! ALSO, LINUX ONLINE DOES NOT ENDORSE THE WORLD DOMINATION SCHEMES OF SPECTRE. THIS IS ONLY USED AS AN EXAMPLE. THE ONLY WORLD DOMINATION SCHEME WE ENDORSE IS THAT OF LINUS TORVALDS.

We should also point out something that you've probably already noticed in the two examples above; that they end with

command >/dev/null 2>&1

We tacked this on the end because cron, by default, mails a "report" to you of the command you carried out. This is so you can either get the output directly in the mail, and/or to see if the command was successful. You may have made a mistake when you added an entry to your crontab (like typing the wrong path or the name of a command wrong). That way, you're notified and even if your job was important and you missed the first one, you can correct it and then you won't miss any others. Again, in the examples above, if we got a mail every time the command was carried out (every minute or couple of minutes), your in-box would quickly fill up with useless mail. Therefore, we tack that on so that cron will send notification of those jobs to /dev/null (ie. the trash).

Here are some other examples of variations:

• 0 0 15,30 * * cat /var/log/mysql.log > $HOME/mysql_use

• 30 8 * * 1-5 /usr/bin/who

The first one makes use of the comma, which means 'and'. In the first example, we see that we will get a report of MySQL use on the 15th and 30th of every month (except February, of course!). The second one will run 'who' which tell us who is logged in, every weekday (1-5) at 8:30 AM. This would be a particularly good one for systems administrators who want to see who's working (or at least who's logged-in) at the time they also start work.

Permissions for cron

The ability to use cron is regulated in the same way as 'at'. Those in

/etc/cron.deny

/etc/cron.allow

cron.hourly, cron.daily and cron.monthly

Most Linux distributions have three directories in /etc called cron.hourly, cron.daily and cron.monthly, which, as you may have already guessed, lets the systems administrator run jobs on an hourly, daily or monthly basis. Simply by placing a shell script here, jobs can be carried out at those intervals. There is no need to have a crontab entry for these jobs.

As you can see, the sky is the limit with the things that you can do with cron. It won't get you to the point where you've programmed absolutely everything, letting you pass your working hours at the beach, but it will make your life a whole lot simpler.