How to deal with crontab in a Service Guard Environment.

[Generic User OI IIS]

Hi Admins,

Any ideas or tips how to deal with crontab in a Service Guard Environment.

I would like to recover the crontab to the adoptive node.

Any hints ?

TIA,

Willy Schriemer.

[Robert Thorneycroft]

Just a guess as I have not tried this myself but create a link from /var/spool/cron/crontabs to a crontab file stored on one of your shared disks. You could also setup your standard crontab for when the node is not running as your primary server in a directory under the mount point so things will work when the disks are not mounted.

*Disclaimer* I have not tried this myself so I do not know if it works, it is just the 1st thing I would try.

Kind regards,

Robert Thorneycroft

[Stefan Farrelly]

The best way weve found to do it in an SG environment is to keep a copy of one nodes crontab entries in the crontab for the other nodes, but commented out. That way in the event of a failure all you have to do is uncomment the entries for the down node.

eg.
00 23 * * * /usr/local/bin/backup.Node1
#00 23 * * * /usr/local/bin/backup.Node2

Other ways include changing each cron script to check for nodename and thus decide to run or not - but as we added more to cron this because time consuming.
Or place the crontab files on a shared drive so theyre always available if a node is down, all you need to do is crontab the entry for the downed node - but this would then overwrite the crontab entry for the current node - hence we used the first option above.

[Christopher Caldwell]

Not too elegant:
If we're just going to be moved for a bit, we blow off cron. If we're going to be moved for a while, we rcp/merge the cron files.

[Carlos Fernandez Riera]

I added the control into the scripts :

set $(cmviewcl | grep pkg_name)

if [ $2 = "up" -a $3 = "running" -a $5 = $(hostname) ] ; then
....

fi

[Robin Wakefield]

Hi Willy,

We have a wrapper in front of all the cronjobs that are cluster-dependent, e.g.

0,30 * * * * /usr/local/bin/ClustWrap /usr/local/bin/omni_mount_check

That way the crontab can be the same on all nodes.

/usr/local/bin/ClustWrap:

===========================================
#!/sbin/sh

# Set IFS to
IFS='
'
export IFS

PATH=/usr/bin:$PATH
export PATH
SHELL=/sbin/sh
export SHELL
LOG=/var/tmp/clustwrap.log
PKG=om
JOB=$@
UNAME=`hostname`

MSG="`date +'%d/%m/%y %T'`: CRON NOTICE ClustWrap:"

# while we're here, trim file to 100000 bytes
SIZE=`wc -c $LOG | cut -f 1 -d " "`
SIZE=${SIZE:-100001}
if [ $SIZE -gt 100000 ] ; then
mv -f $LOG ${LOG}.old 2>/dev/null
touch $LOG
chmod 644 $LOG
chown root:sys $LOG
fi

# Check whether package is running at all, if so get current node
## CNODE=`/usr/sbin/cmviewcl -p $PKG 2> /dev/null|tail -1|grep running|awk '{print $NF}' `
#
# Don't worry about specific package names, just check if any package is running on this node...
CNODE=`/usr/sbin/cmviewcl -l package 2>/dev/null | grep running | awk '{print $NF}'`
CNODE=${CNODE:-DOWN}
if [ "$CNODE" != "DOWN" ]
then
echo $CNODE | grep -q $UNAME
if [ $? -eq 0 ]
then
echo "$MSG OpenMail package running on this node" >> $LOG
echo "$MSG $UNAME, running cronjob $JOB" >> $LOG
# Run cronjob as set in crontab
exec "$@"
else
echo "$MSG OpenMail package NOT running on this node `hostname`" >> $LOG
### echo "$MSG Should run cronjob $JOB on $CNODE" >> $LOG
fi
else
echo "$MSG OpenMail package NOT running in" >> $LOG
echo "$MSG cluster, cronjob $JOB NOT RUN" >> $LOG
fi

exit 0

==============================================

Rgds, Robin

[Stephen Doud]

Another way:

A simple way to cron special procedures when a package starts on the node is to
load a package-specific cronjob list when the package starts.

/var/spool/cron/crontabs is a logical location to place the cronjob files
of various users and package cronjobs.

In customer_defined_run_cmds section of the package control script, add
the line:

su -c "crontab /var/spool/cron/crontabs/"

Likewise, in customer_defined_halt_cmds section, instruct the system to
forget the new cron tasks by adding the line:

crontab -r

If it is necessary that the root user should be the host of the new cron
tasks, crontab a "package_up" cronjob file when the package starts. Since the
crontab command can only reference one file, concatenate both the standard
cronjob list and the "package_up" cronjob file to present to the crontab
command:

In customer_defined_run_cmds cat /var/spool/cron/crontabs/root /var/spool/cron/crontabs/root_pkg1 > /var/spool/cron/crontabs/root_pkg1_up
crontab /var/spool/cron/crontabs/root_pkg1_up

When the package halts, crontab the standard root cronjob file
under/var/spool/cron/crontabs which is the same file sourced at boot time.

crontab /var/spool/cron/crontabs/root

-s.