serviceguard and crontab (associating crontab files to packages)

[Daryl Much]

I have inherited an active/active, 2-node mc/sg cluster (hpux 11i and mc/sg 11.14). Is there a way to associate specific crontab files with a package? I've tried a few ways using a combination of either 1) symlinks to individual crontab files or 2) symlinks to crontab directories and then putting hard links into the directories for the needed crontabs. These work ok until one does a crontab -e. This will either replace the symlink with a regular file, or wil replace one of the hardlinks with a new file. there are a couple other issues with these approaches so I'm wondering if there are other strategies I'm not aware of.

Thanks,

Chuck Davis

[Steven E. Protter]

You only want the cron jobs to run when the package is running on the node? Then build that fucntionality into the package script.

cron does what you tell it to. It works for you.

You can right a cron job that only acts when the package is running on the node.

What I don't think you can do is this symlink thing.

Another thing you can do with cron is have it detect whether the node and or its packages are functioning correctly and change that circumstance.

Its all a matter of detecting the condition and then issuing the appropriate commands.

SEP

[A. Clay Stephenson]

Generally the most foolproof method is to have a cronjob on every possible adoptive node and let each cronjob test for the existence of a file. Presumably the file will only be found when the volume group under the package has activated the VG and mounted the filesystem.

[Daryl Much]

Thanks for replies. part of the problem is the crontabs reference scripts that live on LV's that belong to packages. Therefore, the scripts aren't available unless the package is up (at which point theres no need to check for the package running) and if the package isn't up I get a bunch of junk mail from cron that it can't find the script. It's kind of a chicken/egg dilemma. I could move the cron scripts to non-shared storage but then I'd need to sync the 2 nodes for any changes which is something I'd like to avoid. The whole thing was ported to mc/sg a few years ago and this part was never really worked out.

FWIW, the symlink directory hack works pretty well it just seems so inelegant (i've been doing it for over a year now). I am basically using the package start script to stop cron, change the dir symlink, then restart cron. The only crontab needed when the cluster/package is not running is root. It gets out of sync when I use "crontab -e". This is what's in the package start script:

/sbin/init.d/cron stop
rm /var/spool/cron/crontabs
(cd /var/spool/cron; ln -s crontabs.cluster_running crontabs)
/sbin/init.d/cron start

I have a similar entry for the package stop script which links to the crontabs.cluster_not_running directory.
I guess I'll probably stick to this strategy since it's in place alreay, fairly easy to maintain, and the developers can do whatever they want w/ their scripts. I'll probably write yet another cron script (yacs) to keep the root crontabs synched up.

Thanks a lot for the input.

Regards,

Chuck Davis

[Geoff Wild · Accepted solution]

This is how I do it in cron:

# clean up old PCT data
30 5 * * * [ -d /oracle/PRD/920_64 ] && /usr/local/bin/pct.clean >/dev/null 2>&1


Basically - it's an if statement in cron - if the directory /oracle/PRD/920_64 exists, then (&&) run my script /usr/local/bin/pct.clean

Rgds...Geoff

[Henrik Rasmussen]

The way i've done it is to run a script "cmcronpkgpresent.sh" (attached) in every cron entry that checkes whether the package is running on the particular node or not, using cmviewcl:

cmcronpkgpresent -p package command

like

00 18 * * 1-5 /usr/contrib/bin/cmcronpkgpresent -p MYPACKAGE /bin/su anotheruser -c "whoami"

The script only executes the command if the package in running on the node, but the cron-entry runs on all nodes.

Yet another script distribute the crontab from one of the nodes to the others every hour using crontab -l > distfile, distributing the distfile and enter the crontab on the other nodes using crontab -l < distfile

This way I do all cron maintainance on one of my nodes and ensures that the cron is always the same.

[Daryl Much]

Thanks for the excellent examples. I will probably implement a combination of them and get away from my symlink hack (although it's been working reasonably well). Of course that's an important point keeping the /var/spool/cron/crontabs in sync between servers. For that I will look into doing a rsync followed by a cron stop/start bounce and ensure that I do my crontab maintenance on only one box.

Thanks again.

Regards,

Chuck Davis