5

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?

9
  • Without rebooting I assume?
    – terdon
    Sep 23, 2013 at 22:13
  • I don't think you can do this without either restarting the service or a reboot.
    – slm
    Sep 23, 2013 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, 2013 at 22:29
  • I don't think so, but you could do something like this, t ake a look at this Q: stackoverflow.com/questions/4304631/rescheduling-an-at-job
    – slm
    Sep 23, 2013 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, 2013 at 22:47

1 Answer 1

10

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
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.