This is my current system date

root@48392:/home/# date
Mon Apr 25 19:08:13 CEST 2016

Now I set up an at job...

root@48392:/home/# echo "ls" | at now
warning: commands will be executed using /bin/sh
job 111254 at Mon Apr 25 19:09:00 2016

according to at, job 111254 will run on

Thu Nov 12 19:11:00 2054
  • 1
    Do you get a sensible time if you use "now +1 minute"? – roaima Apr 25 '16 at 18:22

With regards to now the man at states that:

 You can also give times like now + count time-units, where the  
 time-units can be minutes, hours, days, or weeks

Nowhere does it say it is allowed to use at now without such an additional count of time-units, so I am not surprised you get undefined/unexpected behaviour.

  • Interestingly, the date "Thu Nov 12 19:11:00 2054" cannot even be parsed or converted to Epoch time. It would have been interesting to find out which weird arithmetic error produced this date from the current system date. – Guido Apr 25 '16 at 17:52
  • The definitive TIMESPEC yacc grammar does permit "now". Contrary to the man page it is acceptable without any subsequent token. (However I've not had time to check what "now" actually means.) – roaima Apr 25 '16 at 18:17
  • 1
    On my system at now does what you might expect, and runs the job immediately (subject to queue limits). – roaima Apr 25 '16 at 22:09

It appears at now is setting the time as far in the future as possible when parsing of the time string now fails. The command batch is intended to run now, or at least as close to now as load permits.

You may be able to reschedule by using atq to cat the job to an at request with the desired time. The man page for at, batch and related commands should give you more information

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.