This show has been flagged as Clean by the host.
This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems.
I would imagine that most users of UNIX-like systems have heard of
cron
—certainly any system administrator should have. Briefly,
cron
is a way of running a job repeatedly based on the time and date; for example, a job could run every hour, at 5:00am every Tuesday, or the 3rd of every month. It is commonly used for administrative or maintenance tasks that should be done on a regular schedule, such as checking for software updates, rotating log files, or updating the database for the
locate
command.
As well-known as
cron
is, there is a similar utility that very few seem to be aware of:
at
. This is the word "at", and has nothing to do with the at symbol "@". An
at
job is very much like a
cron
job, except that an
at
job only runs one time. A job is submitted by running
at
timespec
1
, where
timespec
is the time and date the job is to be run. The linked POSIX specification page describes acceptable formats for
timespec
; some examples are "
now
", "
14:00
", "
noon tomorrow
", "
14:00 + 3 months
", and "
14:00 January 19, 2038
". The utility then waits on standard input for you to enter a set of commands to be run in the job. You end input by typing
Control-D
to mark the end of text. (As an alternative to typing in the job, you could instead use the "<" symbol to redirect standard input to come from a file containing the commands you want to run.)
When the specified time arrives, the job will be run. That is the theory, anyway, but some things may interfere. The normal configuration for some implementations only checks for due
at
jobs every five minutes, so there can be a delay before a job is actually run. Also, if the system isn't running, obviously it can't execute any jobs. When it comes back up, typically it will check for any pending
at
jobs that are currently or past due and run those. It is best to think about an
at
job being run no earlier than the time it was scheduled for, and probably soon after, provided the system is up. The POSIX standard doesn't specify anything about when jobs are actually run, just that they are
scheduled
for a particular date and time.
The user does
not
need to be logged in for a job to run—if the job outputs anything to standard output or standard error, that text will be e-mailed to the user, presuming the system is set up to send mail. This is often true for a server, which might be running a Mail Transfer Agent like
sendmail
,
postfix
, or
exim
, but many desktops are not. If nothing is output to standard output or standard error, or if that output is redirected to a file, then mail will not be sent on job completion. This behavior can be changed with the
-m
option; in that case, mail will always be sent when the job finishes whether or not there is any output.
The
batch
command is very similar
2
—POSIX specifies it as being equivalent to
at now
with two differences. First, jobs are put into a different queue, and second, mail is always sent when a job completes as if the
-m
option was used with
at
. In practice, however, certain aspects of the behavior of
batch
depend on the implementation.
On the large majority of systems I investigated
3,4,5,6,7,8
, but not all
9
,
batch
jobs will only be run when the system load level drops below a certain point. This can typically be configured by the administrator but has a default value—the manual pages for a couple systems don't actually list a default value and just say
batch
jobs will run "when system load levels permit". Basing execution on the load level makes sense if the
batch
utility is seen as a way of running potentially resource-intensive jobs when the system is not being heavily used. However, this behavior is not required by POSIX.
Another question that the standard leaves unanswered is how queues behave. From the normal understanding of the word "queue", you might expect that each successive job is run one at a time once the previous job completes. However, this is not stated in POSIX, and some implementations explicitly allow a configurable number of jobs to run simultaneously. Manual pages for other systems simply don't mention the subject. (I researched this episode by looking at documentation for a number of BSD, Linux, and commercial UNIX systems, but didn't actually test out how they behave.) POSIX only requires systems to have two queues, one named "a" for
at
jobs and one named "b" for
batch
jobs, but allows implementations to have more. It says nothing about how different queues compete for resources—one implementation assigns a higher
nice
value to jobs in a queue whose name comes later in the alphabet, giving them a lower priority in the process scheduler.
So what good are
at
and
batch
? While I think they certainly meet the "obscure" requirement for a UNIX Curio, I have to admit they aren't particularly useful today. They were designed for an era where a typical UNIX-like system would run around the clock and had multiple users who might log in at various times of the day but weren't connected 24/7. In that context, using
batch
to run a job when the system is lightly loaded might be useful; nowadays, you can just run it whenever you like on your own machine. I have never actually used
batch
myself. On a machine where there is serious competition for resources among users,
batch
is probably not a sophisticated enough tool to manage their jobs—the NetBSD and Debian manual pages explicitly suggest using something different
3,6
. Supercomputing environments have even more complex requirements and a number of specialized solutions exist for scheduling jobs there.
I
have
used
at
a couple of times. One example was for an organization I was part of that had paid for its domain name registration several years into the future. On the organization's server, I set an
at
job to e-mail the administrator a reminder to renew it a few months before the domain was due to expire. It was useful in that case because I didn't know whether I would even continue to be involved then, so a personal reminder for myself wouldn't necessarily help. But in my experience, administrative tasks don't tend to be one-off events. Instead, they repeat, making
cron
the right tool to use. For reminders, a calendar app is probably a better solution in most cases.
While you might never have a use for
at
and
batch
, I still think it's good to know that they exist. Just be aware that you'll probably need to read the manual page on your system to fully understand how they will behave.
References:
At specification
https://pubs.opengroup.org/onlinepubs/009695399/utilities/at.html
Batch specification
https://pubs.opengroup.org/onlinepubs/009695399/utilities/batch.html
NetBSD 10.0 at manual page
https://man.netbsd.org/NetBSD-10.0/at.1
FreeBSD 15.0 at manual page
https://man.freebsd.org/cgi/man.cgi?query=at&sektion=1&manpath=FreeBSD+15.0-RELEASE+and+Ports
OpenBSD 7.8 at manual page
https://man.openbsd.org/OpenBSD-7.8/at.1
Debian 13 at manual page
https://manpages.debian.org/trixie/at/at.1.en.html
openSUSE 42.3 at manual page
https://man.freebsd.org/cgi/man.cgi?query=at&sektion=1&manpath=openSUSE+42.3
HP-UX Reference (11i v3 07/02) - 1 User Commands A-M (vol 1)
https://support.hpe.com/hpesc/public/docDisplay?docId=c01922490&docLocale=en_US
OpenSolaris 2010.03 at manual page
https://man.freebsd.org/cgi/man.cgi?query=at&sektion=1&manpath=OpenSolaris+2010.03
Apologies for the "tapping" sound that occurs in parts of this episode. I think my microphone must have picked up some electromagnetic interference.
Provide feedback on this episode.
Denmark