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 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.

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

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.

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

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