echo wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2;
tar xvfjp linux-2.6.10.tar.bz2 > myjob.job
at -f myjob.job tomorrow
As you can see, at is flexible about the time format it takes; you can specify it in three ways:
> Using the now parameter, you can specify a number of minutes, hours, days, or weeks relative to the current time — for example, now + 4 weeks would run the command one month from today.
> You can also specify several special times, including tomorrow, midnight, noon, or teatime (4 p.m.). If you do not specify a time with tomorrow, your job is set for precisely 24 hours from the current time.
> You can specify an exact date and time using HH:MM MM/DD/YY format — for example, 16:40 22/12/05 for 4:40 p.m. on the 22nd of December 2005.
When your job is submitted, at reports the job number, date, and time that the job will be executed; the queue identifier; plus the job owner (you). It also captures all your environment variables and stores them along with the job so that, when your job runs, it can restore the variables, preserving your execution environment.
The job number and job queue identifier are both important. When you schedule a job using at, it is placed into queue a by default, which means it runs at your specified time and takes up a normal amount of resources.
There is an alternative command, batch, which is really just a shell script that calls at with a few extra options. These options (-q b -m now, if you were interested) set at to run on queue b (-q b), mailing the user on completion (- m), and running immediately (now). The queue part is what is important: Jobs scheduled on queue b are executed only when the system load falls below 0.8 — that is, when the system is not running at full load. Furthermore, they run with a lower niceness, meaning queue a jobs usually have a niceness of 2, whereas queue b jobs have a niceness of 4.
Because batch always specifies now as its time, you need not specify your own time; it simply runs as soon as the system is quiet. Having a default niceness of 4 means that batched commands get fewer system resources than queue jobs (at's default) and fewer system resources than most other programs. You can optionally specify other queues using at. Queue c runs at niceness 6, queue d runs at niceness 8, and so on. However, it is important to note that the system load is checked only before the command is run. If the load is lower than 0.8, your batch job is run. If the system load subsequently rises beyond 0.8, your batch job continues to run, albeit in the background, thanks to its niceness value.
When you submit a job for execution, you are also returned a job number. If you forget this or just want to see a list of other jobs you have scheduled to run later, use the atq command with no parameters. If you run this as a normal user, it prints only your jobs; running it as a super-user prints everyone's jobs. The output is in the same format as when you submit a job, so you get the ID number, execution time, queue ID, and owner of each job.
If you want to delete a job, use the atrm command followed by the ID number of the job you want to delete. The next example shows atq and atrm being used to list jobs and delete one:
[paul@caitlin ~]$ atq
14 2005-01-20 23:33 a paul
16 2005-02-03 22:34 a paul
17 2005-01-25 22:34 a paul
15 2005-01-22 04:34 a paul
18 2005-01-22 01:35 b paul
[paul@caitlin ~]$ atrm 16
[paul@caitlin ~]$ atq
14 2005-01-20 23:33 a paul
17 2005-01-25 22:34 a paul
15 2005-01-22 04:34 a paul
18 2005-01-22 01:35 b paul
In that example, job 16 is deleted by atrm, and so it does not show up in the second call to atq.
The default configuration for at and batch is to allow everyone to use it, which is not always the desired behavior. Access is controlled through two files: /etc/at.allow, and /etc/at.deny. By default, at.deny exists but is empty, which allows everyone to use at and batch. You can enter usernames into at.deny, one per line, to stop those users scheduling jobs.
Alternatively, you can use the at.allow file; this does not exist by default. If you have a blank at.allow file, no one except root is allowed to schedule jobs. As with at.deny, you can add usernames to at.allow one per line, and those users can schedule jobs. You should use either at.deny or at.allow: When someone tries to run at or batch, Fedora checks for the username in at.allow. If it is in there, or if at.allow does not exist, Fedora checks for the username in at.deny. If the username is in at.deny or at.deny does not exist, the user is not allowed to schedule jobs.
Using cron to Run Jobs Repeatedly
The at and batch commands work well if you want to execute a just single task at a later date, but they are less useful if you want to run a task frequently. Instead, there is the crond daemon for running tasks repeatedly based on system — and user — requests. cron has a similar permissions system to at: Users listed in the cron.deny file are not allowed to use cron, and users listed in the cron.allow file are. An empty cron.deny file — the default — means everyone can set jobs. An empty cron.allow file means that no one (except root) can set jobs.
There are two types of jobs: system jobs and user jobs. Only root can edit cron.allow or does not appear in cron.deny can run crontab file, which by default looks like this:
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
1 * * * * root run-parts /etc/cron.hourly
2 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
The first four lines are optional: SHELL specifies which shell should be used to execute the job (defaults to the shell of the user who owns the crontab file, usually /bin/bash), PATH specifies the search path for executables to use, and you should avoid using environment variables there. MAILTO defines to whom mail should be sent. If this is not set, it uses the owner of the crontab, but if you do not want to receive mail when your job
