views:

1237

answers:

4

Hi,

I'm trying to write a web frontend for Crontab in Ruby using the excellent CronEdit gem. I went through Dillon Cron's crontab source code and found that it updates a particular file so that the daemon will refresh the cron list during the next sweep.

In man crontab for VixieCron, it says:

Additionally, cron checks each minute to see if its spool directory’s modtime
(or the modtime on /etc/crontab) has changed, and if it has, cron will then 
examine the modtime on all crontabs and reload those which have changed. 
Thus cron need not be restarted whenever a crontab file is modified. Note that
the crontab(1) command updates the modtime of the spool directory whenever it
changes a crontab.

Is there any platform (Ubuntu, Red Hat, ArchLinux, Mac OS X) independent way to ensure that after manually editing the Cron file, the daemon refreshes it without fail?

+2  A: 

Sane modern linux distros have /etc/cron.d/ directory where you can put your crontab entry as a separate file. If I recall correctly the new cronfile gets read within 2 minutes of being written

gnibbler
+4  A: 

No, there isn't. If you know it's VixieCron, then update the timestamp of the directory. Otherwise, you might be able to fake it: Set the env variable EDITOR before you invoke crontab -e (which should bring up an editor for the crontab).

The idea is to set the editor to some program which makes the change. crontab -e will wait for the editor to terminate and reread the file and tell cron that something has changed.

If you have an old version of cron, though, you must still restart it. But I doubt that you can find such ancient versions on anything that runs Linux or Mac OS X.

Aaron Digulla
Well, no, but still, I think most of the crontab implementations support atomic updates via the crontab(8) command, so you can do this: `crontab -l > CT`, edit CT, `crontab CT` and you don't have to worry about timestamps etc. Or `crontab -` and feed the updated tab on STDIN.
conny
A: 

If this is that important, why not use a different lever? In other words, there are two options:

crontab 1: /do/some/very/specific/thing with specific parameters that i need to change etc.

crontab 2: /do/what/needs/to/be/done

In #2, the job is responsible for determining at run time what needs to be done and doing it. With this design, the notion of needing to understand how crontab works on some detailed level is irrelevant.

Mark McEahern
+1  A: 

Thank you very much gnibbler and Aaron. I just went through the source code for both 'whenever' and 'cronedit' gems for Ruby. Both of them does a 'crontab -' which replaces the existing cron file with the updated cron entries. That means contrary to my original question, these libraries make use of the standard crontab tool which in turn would do whatever specifics necessary to refresh the daemon.

I think the best platform-independent, and cron (dillon, vixie, mcron etc.) agnostic way to refresh the daemon is to always use the associated crontab utility. Even when editing programmatically, the user-program must pass the new cron file to the crontab utility which would do whatever is required by that specific platform/cron.

@Mark, thank you for the comments. However, I'm trying to provide a simple web frontend that the user can customize through the www just like editing the crontab file directly.

Thank you so much for your responses!

Jasim
Oh. I just wrote another comment saying the same thing. Should have read all answers before posting :)
conny