cron in serviceguard

[p7]

hi all

i want serviceguard to start not cron, not the system. i put /sbin/init.d/cron start in the package script, but when i put /etc/rc.config.d/cron to 0 it didnt work. i even tried putting /usr/sbin/cron in the package script but that didnt work either when
/etc/rc.config/cron is set to 0. has anyone ever worked a way around that?

thx in advance

[Dennis Handly · Accepted solution]

>I want serviceguard to start cron, not the system.

Why? Can't you fix your crontab entries to wait until Serviceguard is up?

>when I put /etc/rc.config.d/cron to 0 it didn't work.

This tells /sbin/init.d/cron to never start.
If you don't want rc(1m) to start it, you need to remove the symlink in one of the /sbin/rcN.d/ directories.
(I assume you don't care about the stop script.)

[Steven E. Protter]

Shalom Pasquale,

I'm having trouble understanding the goal.

Making your scripts run by cron serviceguard aware is probably the way to go.

The cron scrip that is interfering with your (unstated) goals, can be written to check if the serviceguard package is running and do nothing if not.

cmviewcl and a few greps or awk statement can make your script serviceguard aware. Just don't forget to set the PATH in your script.

SEP

[p7]

thx for the responses

the reason is this:

since serviceguard brings up the filesystems, oracle,package failover (if needed) and other apps. the dbas requested that cron not be run until the package is fully up, since they dont want these services potentially trying to run on systems that arent fully up and that created problems for them in the past

thx again

[James R. Ferguson]

Hi:

> since serviceguard brings up the filesystems, oracle,package failover (if needed) and other apps. the dbas requested that cron not be run until the package is fully up, since they dont want these services potentially trying to run on systems that arent fully up and that created problems for them in the past

Then tell your DBA's to fix their scripts to gracefully exit if the required resources aren't yet available. They have asked you to fix *their* problem when it is they who need to address the issue.

Regards!

...JRF...

[Vivek_Pendse]

If you have oracle DB/Apps, then there is a good product of "HP Serviceguard Extension for Oracle E-Business Suite". This will start the DB alongwith package; also if you have Oracle apps, then will make sure that the DB has started first. It's very good product.

[Emil Velez]

Why not just let cron run on both systems. WHen a package starts it adds jobs to cron. When the package stops it can remove jobs from cron.

The cron scripts can be written to make sure the package is local otherwise exit.

[Viktor Balogh]

> Why not just let cron run on both systems. WHen a package starts it adds jobs to cron. When the package stops it can remove jobs from cron.

yepp, this is the method we work with. I recommend you to modify the package start/stop script(s) to read-in the job list from a file (which resides on the shared storage, in the package). If a DBA modifies the crontab with "crontab -e" command, it remains consistent between the nodes: by switching the package the crontab of oracle gets written to a file to the shared storage like this:

# su -oracle -c crontab -l > /package1/oracle/oracle.crontab
# su - oracle -c crontab -r

The second line deactivates the crontab on this node - we don't need the crontab here anymore since the package will be switched. Note the "su - oracle -c" phrases, they are needed because the start/stop script will be run as root.