Cron is nice and all, but don’t forget about its cousin at.
When I first started using Linux, it was like being tossed into the deep end
of the UNIX pool. You were expected to use the command line heavily along
with all the standard utilities and services that came with your
distribution. At lot has changed since then, and nowadays, you can use a
standard Linux desktop without ever having to open a terminal or use old
UNIX services. Even as a sysadmin, these days, you often are a few layers of
abstraction above some of these core services.
I say all of this to point out that for us old-timers, it’s easy to take for
granted that everyone around us innately knows about all the command-line
tools we use. Yet, even though I’ve been using Linux for 20 years, I
still learn about new (to me) command-line tools all the time. In this “Back
to Basics” article series, I plan to cover some of the command-line tools
that those new to Linux may never have used before. For those of you who are
more advanced, I’ll spread out this series, so you can expect future
articles to be more technical. In this article, I describe how to use
the at utility to schedule jobs to run at a later date.
at vs. Cron
at is one of those commands that isn’t discussed very much. When
people talk about scheduling commands, typically cron gets the most
coverage. Cron allows you to schedule commands to be run on a periodic
basis. With cron, you can run a command as frequently as every minute or as
seldom as once a day, week, month or even year. You also can define more
sophisticated rules, so commands run, for example, every five minutes, every
weekday, every other hour and many other combinations. System administrators sometimes
will use cron to schedule a local script to collect metrics every minute or
to schedule backups.
On the other hand, although the at command also allows you to schedule
commands, it serves a completely different purpose from cron. While cron
lets you schedule commands to run periodically, at lets you schedule
commands that run only once at a particular time in the future. This
means that at fills a different and usually more immediate need
from cron.
Using at
At one point, the at command came standard on most Linux
distributions, but
these days, even on servers, you may find yourself having to
install the at package explicitly. Once installed, the easiest
way to use at is to type
it on the command line followed by the time you want the command to run:
$ at 18:00
The at command also can accept a number of different time formats. For
instance, it understands AM and PM as well as words like “tomorrow”, so you
could replace the above command with the identical:
$ at 6pm
And, if you want to run the same command at that time tomorrow instead:
$ at 6pm tomorrow
Once you press enter, you’ll drop into an interactive shell:
$ at 6pm tomorrow
warning: commands will be executed using /bin/sh
at>
From the interactive shell, you can enter the command you want to run
at that time. If you want to run multiple commands, press enter after each
command and type the command on the new at> prompt. Once you’re done
entering commands, press Ctrl-D on an empty at> prompt to exit the
interactive shell.
For instance, let’s say I’ve noticed that a particular server has had
problems the past two days at 5:10am for around five minutes, and so far, I’m
not seeing anything in the logs. Although I could just wake up early and log
in to the server, instead I could write a short script that collects data
from ps, netstat, tcpdump and other
command-line tools for a few minutes, so
when I wake up, I can go over the data it collected. Since this is a one-off,
I don’t want to schedule something with cron and risk forgetting about it
and having it run every day, so this is how I would set it up with
at:
$ at 5:09am tomorrow
warning: commands will be executed using /bin/sh
at>
at> /usr/local/bin/my_monitoring_script
Then I would press Ctrl-D, and the shell would exit with this output:
at> <EOT>
job 1 at Wed Sep 26 05:09:00 2018
Managing at Jobs
Once you have scheduled at jobs, it’s useful to be able to pull up a list of
all the at jobs in the queue, so you know what’s running and
when. The atq
command lists the current at queue:
$ atq
1 Wed Sep 26 05:09:00 2018 a kyle
The first column lists the number at assigned to each job and then lists the
time the job will be run and the user it will run as. Let’s say that in
the above example I realize I’ve made a mistake, because my script won’t be able
to run as a regular user. In that case, I would want to use the
atrm command
to remove job number 1:
$ atrm 1
If I were to run atq again, I would see that the job no longer exists.
Then I could sudo up to root and use the at command to schedule the job
again.
at One-Liners
Although at supports an interactive mode, you also can pipe commands to it all
on one line instead. So, for instance, I could schedule the above job with:
$ echo /usr/local/bin/my_monitoring_script | at 5:09am tomorrow
Conclusion
If you didn’t know that at existed, you might find yourself coming up with
all sorts of complicated and convoluted ways to schedule a one-off job. Even
worse, you might need to set an alarm clock so you can wake up extra early
and log in to a problem server. Of course, if you don’t have an alarm clock,
you could use at:
$ echo “aplay /home/kyle/alarm.wav” | at 7am tomorrow
Digital transformation is affecting every industry, from manufacturing to hospitality and government to finance. As a service provider, you’ve probably seen how this period of rapid change is disrupting your customers—causing both stress and growth. Luckily, your customers’ digital transformation can be an opportunity for your organization too.
