Right, so you’ve fired a job into the future with at. Now what? You’re not a fortune teller; you can’t just hope it’ll run. You need to see what’s in the queue, and sometimes, you need to perform a little tactical retreat on a job you just scheduled. That’s where atq and atrm come in. Think of them as your mission control for the at system.

Checking the Queue with atq

The atq command is dead simple. It simply lists the jobs currently pending in the at queue. The name stands for “at queue,” which is refreshingly logical for a Unix command.

$ atq
10      Thu Aug 29 16:00:00 2023 a yourusername
15      Fri Aug 30 09:30:00 2023 a yourusername

See that? It gives you a neat little list. The first number is the job number. Guard this number with your life—or at least, with a sticky note—because it’s the unique identifier you need to manage this specific job. Next, you get the date and time the job is scheduled for, and the queue letter (a), which is almost always ‘a’ for the default queue. Finally, it shows the user who owns the job. This is crucial because, by default, atq only shows your jobs.

Now, if you’re the root user, or feeling nosy (and have the permissions), you can see everyone’s pending jobs. This is where the atq command reveals its secret identity: it’s actually just a symlink to the at command itself. When you call atq, you’re really running at -q (see, the ‘q’ makes sense now!). Because of this, you can use at’s flags.

To see the entire queue, for every user:

sudo atq

Or, if you want to be more official about it:

sudo at -q

The Art of the Cancellation with atrm

You scheduled a job to send a snarky email to your future self. Future you is now present you, and present you realizes that was a terrible idea. Time to delete it. This is where atrm shines. You use it with the job number you got from atq.

$ atrm 10

And poof. Job number 10 is gone from the queue. No ceremony, no confirmation dialogue. It’s a very Unix-philosophy approach: you said to delete it, so it assumes you’re sure. Double-check that job number before you hit enter.

What if you need to nuke all your pending jobs? You can be clever with a one-liner, using atq to get the list and awk to pluck out the job numbers for atrm.

atq | awk '{ print $1 }' | xargs atrm

Let’s break that down: atq lists your jobs. awk '{ print $1 }' takes that output and prints only the first field (the job number). Then, xargs takes that list of numbers and feeds them one-by-one as arguments to atrm. It’s a thing of beauty.

Permissions and the Real World

Here’s where things get a bit… interesting. The at system has a permissions model that feels like it was designed by a paranoid sysadmin from 1985 (because it was). Access is controlled by two files: /etc/at.allow and /etc/at.deny.

The rule is simple, and brutal:

  1. If at.allow exists, only users listed in it can use at and atq.
  2. If at.allow does NOT exist, but at.deny does, then everyone except users in at.deny can use it.
  3. If neither file exists, only root can use it.

Yes, you read that right. On a fresh install, you might be locked out. This is the number one reason you might run atq and get no output, even when you’re sure you scheduled something. You’re not going crazy; the system just doesn’t trust you. The fix? Have your system administrator add your username to /etc/at.allow or, if at.deny exists and is empty, that means everyone is allowed.

Why This Still Matters

You might be thinking, “This is all a bit archaic. I have cron for everything.” And you’re not wrong. But at’s beauty is in its one-off nature. Needing to run a backup after a long script finishes at an unpredictable time? echo "my_backup_script.sh" | at 03:00. Want to kill that process if it’s still running in an hour? echo "pkill -f my_script" | at now + 1 hour.

atq and atrm are your controls for this simple, powerful system. They give you visibility and a kill switch. Use them to keep your future, scheduled self from doing something your present self will regret.