Managing User Scheduling with the atrun Command

The cron daemon is useful for scheduling regularly run programs, or performing regular tasks, as you found out in Hour 18, "Personal Productivity Tools." The at command is useful for one-time or reminder jobs. Even though your Linux system is set up automatically after installation to handle user at scheduling requests, you should know how to manage the at command facilities for at least one good reason.

By default, when a user uses the at command, the command is run with a default CPU priority. If too many users start running tasks with higher priorities, or CPU-intensive programs in the background, your system's performance could be affected. Read on to learn to manage your system's at command facilities to provide the best performance and control possible.

Your system's at command facilities are enabled by the cron daemon, which, after starting when you boot Linux, checks the /etc/crontab file, and sees the following entry:

...

# Run any at jobs every minute

* * * * * root [ -x /usr/sbin/atrun ] && /usr/sbin/atrun

...

As you can see, this is why the at command depends on the cron command; the cron command runs the atrun command, found under the /usr/sbin directory, each minute your system is up. The atrun command in turn, then searches the /var/spool/at directory to look for jobs to run. For example, if the root operator creates a job at 19:30 for that day, you'd see the following:

# at 19:30

echo Hello

Job 9 will be executed using /bin/sh

# ls -l /var/spool/at

-rwx------   1 root     root         3144 Nov 26 19:25 c0000900dff21e

-rwx------   1 bball    bball        3146 Nov 26 19:26 c0000a00dff21e

drwx------   2 daemon   daemon       1024 Nov 26 19:04 spool

As you can see, there is a job waiting for the root operator and the user bball. Each of the files beginning with a "c" contains a shell script to execute the job (in the case of the root at job, it is only to echo the word job, which will be emailed after the job executes).

So now that you know how the at facilities run, how do you control how at works, and for

whom, on your system? One way to control the performance, is to use the atrun command's -l (load average) option. This option will control any jobs submitted by users using the batch command (discussed in Hour 18 with the at command). You can limit when batch jobs are run by specifying a number lower than 1.5 (the default), which tells atrun to run batch jobs only when the system load average (determined by a value in the /proc/loadavg file while the system is running) is low.

You can see the current load average with

# cat /proc/loadavg

0.20 0.11 0.03 2/50 1228

This shows the load average for the last 5, 10, and 15 minutes. You can also get the load average by using the uptime command, for example:

# uptime

  7:40pm  up  2:44,  3 users,  load average: 0.13, 0.08, 0.02

To allow your users to use batch nearly any time, change the value of the -l option in the atrun command entry in your system's /etc/crontab file to a number higher than the default 1.5 value.

But how do you control whether or not users are allowed to use the at command on your system? By default, after you install Linux, anyone on your system can use the at command. There are four ways to control who can or cannot use the at command. If you look in your /etc directory, you'll see a file called at.deny. Because this file is empty, everyone can use the at command to schedule jobs. If you want to restrict a user from using the at command, put the user's username in the file. If you don't want anyone on your system to use the at command (of course, this doesn't apply to you, because you're the root operator!), then delete the at.deny file from your /etc directory. If you want to allow only certain users to use the at command, then create a file called at.allow in the /etc directory, and put the user's username in the file.

As a final, desperate measure, as the root operator, you can see all the at jobs scheduled on your system with the atq command, and if you see too many jobs scheduled, you can delete them with the atrm command, for example:

#  atq

Date                    Owner   Queue   Job#

20:00:00 11/26/97       bball   c       12

20:10:00 11/26/97       bball   c       13

20:15:00 11/26/97       bball   c       14

20:30:00 11/26/97       bball   c       15

...

# atrm 12 13 14 15 ...

Here I'm assuming you see a long, long list of job numbers, and have deleted them. This is an abrupt, rude way to handle enthusiastic users. A better method may be to email the user and find out if there are tasks being run that may be automated during off-hour or off-

peak times.

As the system administrator, you have complete control of scheduling commands for the users of your Linux system. Think about tasks you should run hourly, daily, weekly, and monthly. With a little imagination, you'll soon automate any custom tools, command lines, and reports you've created to help you manage your system. You'll end up with more disk space, a better running system, and happier users.