1

I have a C++ program that needs to schedule various future processes to kick off on a one-time-only basis.

The development is in Linux so the obvious choice is to use the 'at' command; I'm not interested in writing my own job scheduler!

However I'm reluctant to fork an OS process from my program to call the 'at' executable directly - as this is messy, and cumbersome.

With cron, I know you can write jobs as files out to /etc/cron.d without the need to fork to crontab. However no such facility seems to exist for 'at'.

A bit of research has lead me to the conclusion that I could simply write files to /var/spool/cron/atjobs using the formant axxxxxyyyyyyyy where x=job id and y = hex epoch time in minutes - but this hardly seems in the spirit of Linux security or convention.... plus the filename format is not portable across all *nix systems, should I wish to use another operating system.

Of course I could use cron, but it doesn't sensibly cater for one-time-only jobs, so this doesn't strike me as a good solution either. Nor do I want to grab the source for these tools and rework the necessary bits into my program - this too isn't exactly portable.

So my question is - if I want to schedule execution of future jobs at a given time and date for a single run can anyone suggest a programatically 'nice' way of either interfacing 'at' or the cron daemon directly without having to fork to the OS in C++.... or is there another standard tool that provides this?

hlovdal
  • 23,353
  • 10
  • 78
  • 148
Phil
  • 11
  • 2
  • 1
    I don't know if that counts as "writing your own job scheduler" but `boost::asio` can deal with this quite easily. (not using `at`) – ereOn May 24 '11 at 14:12
  • 1
    @ereOn: how is a network library going to help with scheduling? – Jay May 24 '11 at 14:15
  • @Jay it includes built-in timer support. You can very easily use it to schedule a function to run at a specific time. – SoapBox May 28 '11 at 18:09

3 Answers3

1

The at command seems like a fine way to do things. Why not write the messy code and move on to more important issues.

Jay
  • 12,504
  • 3
  • 36
  • 65
  • A fair point I admit, and short of any revelations on here, this is IMHO the most acceptable of the options I've set out above. I wanted to check I wasn't missing a trick, before I went with this tho. Thanks. – Phil May 24 '11 at 14:25
0

Pure c or c++ way would be to check the current time, and see if a job expired, when you fork a process and execute the application (most likely with system).

BЈовић
  • 57,268
  • 38
  • 158
  • 253
  • Thanks for the response, but sounds like you are suggesting I write the scheduler myself? The program I'm working on isn't memory resident, it will run itself on a regular schedule - schedule some jobs and then terminate, so it is not in a position to monitor the jobs itself. Of course I could write a scheduler process, but it's a distraction from what I'm trying to do, and was hoping to piggy back off an already available (free) 3rd party library or linux tool. – Phil May 24 '11 at 14:18
0

Phil, I would suggest that your own idea of writing job specifications directly into the atjobs directory is the most programmatically elegant means of achieving your goal. This is what the "at" command does anyway (can use strace to track the "at" process when it's queuing a job, superuser privileges are required!).

What is your basis for believing that the location of the cron spool directory is variable?, in my experience such file system paths are usually quite reliable. The only notable departure from this rule is the "etc" directory which is highly system dependent but only between redhat and debian based systems.

Having said all that, you may be biting off a fairly complex chunk of work for a questionable return on that effort (particularly for the format of the job files). Certainly as a technical exercise it has much merit but if I was doing this @work, I'd simply use the c "system" function call.

system("at -f test.py '18:30' today");
Gearoid Murphy
  • 10,997
  • 17
  • 60
  • 85