0

What is the best way to schedule a task that is be executed years later? Like execute a script after 4 years.

Is cron the best method for that?

John Gardeniers
  • 27,458
  • 12
  • 55
  • 109
nitins
  • 2,579
  • 15
  • 44
  • 68
  • 4
    I'd be very interesting in knowing of an application for this ability. An interesting question to ponder will be if your computer system will be there four years from now and manned with people who still recall why there is something in the queue to be triggered years later. If I were the sysadm for such a system I might see this as a user error and delete the job altogether. – mdpc Jan 20 '10 at 04:33

2 Answers2

5

You can use at:

$ at 10am Jul 31 2030
warning: commands will be executed using /bin/sh
at> echo Hello
at> <EOT>
job 2 at Wed Jul 31 10:00:00 2030
$ atq
1       Sun Jul 31 10:00:00 2030 a user
$ atrm 1
Mircea Vutcovici
  • 17,619
  • 4
  • 56
  • 83
  • will the task scheduled using "at" be reset on rebooting the server ? We are talking about 4 years ! – nitins Jan 20 '10 at 05:03
  • 1
    No, of course it won't be reset. – womble Jan 20 '10 at 06:06
  • I like that this answers the question asked: I like Phil P's answer that looks at the *why* behind it, though, too: http://serverfault.com/questions/104454/best-way-to-schedule-a-task-that-is-be-excuted-years-later/104467#104467 – warren Jul 21 '10 at 13:48
5

Any computer system which will be running sufficiently unmodified, after four years, that a script remains valid without modificaiton is somewhat static. Any scheduling system which assumes that one box will still be serving the same role so much later is rather optimistic. Hard disk failure or other problems would make it likely that you get to discover whether or not your backups handle storing the "transient" at-jobs.

It would likely be more robust to look instead at "how do I test if maintenance task X has been run such that the lifetime of the data has been extended out past another N months from now"; eg, domains all renewed, SSL certificates not expiring, etc. Then you can run the job daily, weekly, monthly, or some other frequency higher than "yearly". This means that the code gets exercised and you'll be sure it will run. Especially if the tool registers its success somewhere.

If all else fails, a departmental shared calendar with a bunch of reminders, which send email, may be useful. You can be moderately sure that if the calendar is replaced, or migrated to The Cloud, or whatever else, that someone will take the effort to migrate all the events so that the VIPs don't need to re-enter anything. So your reminder will be migrated "for free" without anyone having to remember this task that only happens every four years.

Phil P
  • 3,080
  • 1
  • 16
  • 19
  • 2
    This. Anything on that timescale needs organisational continuity. You need to ensure that it should actually be done after four years and your requirements haven't changed in that time, the files it references haven't moved, the server itself hasn't been replaced. – pjc50 Jan 28 '10 at 16:05
  • the "why" behind what on earth needs to be scheduled 4 *years* in advance is the truly important question – warren Jul 21 '10 at 13:49