Linux Unleashed, Third Edition:cron and at





-->















Previous
Table of Contents
Next




There are more variations possible, but you can see the syntax. If you want the command to execute on Friday, issue the command in one of these formats:



at 8:30 pm Friday < reorg.data
at 20:30 Fir < reorg.data


Some versions of at are even more talented and handle special words. For example, this command will execute the commands next week on Monday:


at 0900 Monday next week < reorg.data


Not all versions of at can handle these complex formats.
When you submit a program to at for execution, you receive a job ID number. The job ID uniquely identifies the at command you just issued. For example, look at the output from this at command:


$ at 6 < do_it
job 827362.a at Wed Aug 31 06:00:00 EDT 1995


In this case, the job ID is 827362.a and the ID is needed to make any changes to the job.
You can list all the jobs you have queued with at using the -l (list) option. The output usually tells you when the command is set to execute, but not what the command is:


$ at -l
user = tparker job 827362.a at Wed Aug 31 06:00:00 EDT 1995
user = tparker job 829283.a at Wed Aug 31 09:30:00 EDT 1995


Some versions of Linux may support the shorter form of the command with atq (display the at queue). If you get an error message when you issue the atq command, you have to use the at -l format.
To remove an at job from the system, you need the job ID and the at -r (remove) command. For example, the following command removes the specified job:


at -r 2892732.a


Linux does not return a message to indicate the job has been canceled, but if you list the queue, you see the job is gone. You can only remove your own jobs (except for root, which can remove any). Some Linux versions support the atrm command as well as the -r option.
All jobs that are queued into at are kept in the directory /usr/spool/cron/atjobs with the job ID number as the file name. As with cron, there is an at.allow and at.deny file in either /usr/lib/cron or /etc/cron.d directories to control who can and can’t use at. As with cron, if you want all users on your system to be able to use at, create an empty cron.deny file.
When an at job is executed, all output (standard output and error messages) are mailed back to the username who submitted the job unless they have been redirected. The at command retains all the environment variables and directory settings of the user. If you look at a queued job in /usr/spool/cron/atjobs, you will see all the variables defined prior to the command about to be executed.
Summary
As you have seen, cron and at are quite easy to use. They are also a system administrator’s best friend because you can automate tiresome tasks like database cleanups, disk space checking, flushing log files, and tape backups with cron or at. While cron and at can’t do everything for you, they can handle repetitive tasks with ease.
Most Linux systems have a number of sample cron files supplied with the operating system. Examine those files (or list the current crontab file while logged in as root) to see what the operating system wants to execute on a regular basis. Use those commands as the starting point and add your own commands. From here there are a number of chapters you can turn to for related information:

Backing up your system is discussed in Chapter 45, “Backups.”
Setting up your Linux system to serve the Internet is discussed in Chapter 47, “Setting Up an Internet Site.”
Applications you can run under Linux are discussed in Chapter 62, “Adabas-D and Other Databases,” through Chapter 64, “Lone Star Software’s Lone-Tar.”





Previous
Table of Contents
Next