cron/rc syncronization

[Michael Murphy_2]

Is there an easy way to execute the cron entries (or a subset of the cron entries) for an id from an RC script (so that we don't have to worry about keeping the entries in rc and cron in sync)? This will allow the application to be up after system reboots as well as after nightly cron application restarts. I know this could be done by storing the commands in a script file - the user is requesting that we don't do it this way due to "we have never done it that way - prefer to keep cron the way it is".

[Robert Gamble]

Michael,

So, is the application started manually after each reboot now ?

[John Poff]

Hi,

It sounds like you just need one script that rc and cron call for starting and stopping your application. I'd suggest asking the user for the commands to start and stop things, put them in a script and test them, and ask them when things need to get started and stopped. Then, let cron and rc call that same script.

Your user shouldn't get a vote on a technical matter like that just because "we've never done it that way before". I'm not trying to be a hard case, [well, maybe I am :)] but sometimes the users just need to provide the requirements and let you provide the engineering for the solution.

Of course, if your user isn't real savvy, you could make a symlink to the one script used by rc, call the symlink in your cron job, and tell them "Hey, look at that, it IS a different script." :)

JP

[Steven E. Protter]

You can always have an rc script that executes a subset of cron.

crontab -l > /tmp/subset

Edit the subset, take out the timing information since rc doesn't work that way.

create a script called what you want in /sbin/init.d that has standard start stop logic in it. Perhaps copy template and use that.

Then paste in the cron commands you need.

It is a bit of a kludge but quite possible.

ln -s /sbin/init.d/newscript /sbin/rc3.d/S800newscript

ln -s /sbin/init.d/newscript /sbin/rc2.d/K200newscript

SEP

[James R. Ferguson]

Hi:

I suggest 'crontab' entries that reference the 'rc' script. In that way, if you change the *script* it's changed for both bootup and for night 'cron's. The "user" should be *you* the administrator setting the standards!

For example, 'cron' could specify:

/sbin/init.d/<scriptname> stop

...and:

/sbin/init.d/<scriptname> start

Regards!

...JRF...

[Robert Gamble]

Michael,

you can get the standard 'start/stop' logic steven pointed out by copying /sbin/init.d/template to /sbin/init.d/new_script and edit appropriately. If you decide to use flags for the script in /etc/rc.config.d, be sure to modify new_script for the intentional typos left in the template. (/etc/rc.config.d, not /etc/rc.config & make sure to change $CONTROL_VARIABLE as appropriate)

Good Luck!

[Michael Murphy_2]

Answers to a few of the responses: The application is started automatically (not manually) after reboot - but the rc and crontabs have much of the same info and changes to one or the other are not automatically reflected in the other (and this has caused problems). The users have also stated that they like to see the actual commands in cron (not a script), and need the ability to start/stop at different times (not sequentially like a script would run them). They have also been known to edit the cron to test - changing the time entries to have cron run in the following minute to do testing "just like cron would run it". I have to agree that I have tested something from the command line and had it run differently in cron...

[Robert Gamble]

Michael,

I see your points. Maybe you could 'sell' them this idea:

a> Have both the cron and rc scripts point to the same file(s), which contains the start/stop commands.
b> Both the rc and cron scripts would just be wrappers that point (or call) to the same executable script.

That should allow for testing of the cron scripts, and still maintain cohesiveness to the rc scripts.

Allow the users to be present during testing of the scripts, and them provide them with a written 'how-to test' guide.

Hope this helps!

[Frank Slootweg]

While the proposed 'common script' solutions are better, you can run "crontab -l" from the rc script and manipulate (i.e. cut(1) the right fields and grep(1) the desired/undesired entries)and execute the results.