Reset atq list to zero?

Question

I have been using at for quite a while now, and I noticed that the at job ids seem to increment forever.

$ atq
332 Mon Sep 23 17:25:00 2013 a cklein
$ # I'm up to 332 at jobs!

Interestingly, at doesn't seem to keep around data about completed jobs.

$ at -c 331
Cannot find jobid 331

Is it possible to reset this job id number back to 0?

I don't think you can do this without either restarting the service or a reboot. — slm, Sep 23 '13 at 22:14
For some reason I can't restart my atd service, I get a start: Rejected send message... error. Do you think that restarting the service would reset that number? — Cory Klein, Sep 23 '13 at 22:29
I don't think so, but you could do something like this, t ake a look at this Q: http://stackoverflow.com/questions/4304631/rescheduling-an-at-job — slm, Sep 23 '13 at 22:43
A better question might be why you want to do this. Are you trying to achieve something specific (in which case there may be a better way) or is this idle curiosity (nothing wrong with that of course)? — terdon, Sep 23 '13 at 22:47
@terdon Naw, it's just idle curiosity. I was curious that none of the files in FILES section of man at seemed to have a reference to this identifier, so I wondered where the number could possibly come from? — Cory Klein, Sep 23 '13 at 22:55
@terdon I saw something where I thought "hmm, I don't understand how that works!" but I couldn't figure it out on my own, so I came here! — Cory Klein, Sep 23 '13 at 22:55
Always good to ask questions, @terdon, if you want to write it up as the answer feel free. — slm, Sep 23 '13 at 23:06
That was not a rebuke, idle curiosity is great and very welcome, bring it on! I just wanted to make sure this was not an XY problem. Anyway, since atd is a demon, I imagine it simply counts the number of commands it has run since its launch and uses that as its job number. I don't see anything very strange in that. — terdon, Sep 23 '13 at 23:57

slm · Accepted Answer · 2013-09-24T01:26:15.140

A restart of the atd service did not reset the job id as we suspected:

Example

some test submissions

$ at -f test.bash now
job 105 at Mon Sep 23 20:04:00 2013
$ at -f test.bash now
job 106 at Mon Sep 23 20:04:00 2013

double checking the spool dir

$ sudo ls -l /var/spool/at/spool/
total 0

a restart of atd

$ sudo /etc/init.d/atd restart Stopping atd: [ OK ] Starting atd: [ OK ]

subsequent test submissions

$ at -f test.bash now
job 107 at Mon Sep 23 20:05:00 2013
$ at -f test.bash now
job 108 at Mon Sep 23 20:05:00 2013

Digging deeper

So if you look at the executable atd with a tool such as lsof you'll notice the following:

$ sudo lsof | grep atd
atd       22341      root  cwd       DIR              253,0      4096    2103653 /var/spool/at
atd       22341      root  rtd       DIR              253,0      4096          2 /
atd       22341      root  txt       REG              253,0     24712    1192814 /usr/sbin/atd
atd       22341      root  mem       REG              253,0     57440     393478 /lib64/libnss_files-2.13.so
atd       22341      root  mem       REG              253,0    387352     393694 /lib64/libfreebl3.so
atd       22341      root  mem       REG              253,0     43304     393695 /lib64/libcrypt-2.13.so
atd       22341      root  mem       REG              253,0     99128     393328 /lib64/libaudit.so.1.0.0
atd       22341      root  mem       REG              253,0     22536     393671 /lib64/libdl-2.13.so
atd       22341      root  mem       REG              253,0   1956608     393664 /lib64/libc-2.13.so
atd       22341      root  mem       REG              253,0     13776     393333 /lib64/libpam_misc.so.0.82.0
atd       22341      root  mem       REG              253,0     55280     393331 /lib64/libpam.so.0.82.2
atd       22341      root  mem       REG              253,0    124592     393682 /lib64/libselinux.so.1
atd       22341      root  mem       REG              253,0    151456     393578 /lib64/ld-2.13.so
atd       22341      root    0u      CHR                1,3       0t0       4066 /dev/null
atd       22341      root    1u      CHR                1,3       0t0       4066 /dev/null
atd       22341      root    2u      CHR                1,3       0t0       4066 /dev/null
atd       22341      root    3uW     REG              253,0         6    1966556 /var/run/atd.pid

Investigating the spool dir.

So there isn't any file open, but there is a directory, /var/spool/at, so let's investigate a little bit further in there:

$ sudo ls -la /var/spool/at/
total 20
drwx------.  3 daemon daemon 4096 Sep 23 20:42 .
drwxr-xr-x. 15 root   root   4096 Aug  8  2011 ..
-rw-------.  1 daemon daemon    6 Sep 23 20:05 .SEQ
drwx------.  2 daemon daemon 4096 Sep 23 20:42 spool

Bingo! There's the thing we're looking for, a file called .SEQ. More the file shows this:

$ sudo more .SEQ 
0006c

We can convince ourselves of the fact that this is the right value using bc to convert this from hex to decimal:

$ echo "ibase=16; 0006C"|bc
108

An experiment

Appears to be putting the number here in hex. We can do a little experiment and change this value to a 0. But first stop the atd service.

$ sudo /etc/init.d/atd stop
...edit file using vim, change it to 0...
$ sudo /etc/init.d/atd start

Now run another test of at:

$ at -f test.bash now
job 1 at Mon Sep 23 20:52:00 2013

And the number has restarted, we're back to 1. If I stop, edit, start it again and put the value 0006c back in:

$ at -f test.bash now
job 109 at Mon Sep 23 20:53:00 2013

Mystery solved.

A note on other distros

The above was sleuthed on a Fedora system, other distros such as Debian & Ubuntu may store the .SEQ file in an entirely different directory. For example Ubuntu stores the file like this:

$ sudo pwd
/var/spool/cron/atjobs
$ sudo ls -la
total 12
drwxrwx--T 2 daemon daemon 4096 Sep 23 21:19 .
drwxr-xr-x 5 root   root   4096 Oct 17  2012 ..
-rw------- 1 daemon daemon    6 Sep 23 21:19 .SEQ