Re: [Linux-cluster] Cron Jobs

From: "Jankowski, Chris" <Chris Jankowski hp com>

To: linux clustering <linux-cluster redhat com>

Subject: Re: [Linux-cluster] Cron Jobs

Date: Tue, 30 Mar 2010 23:48:51 +0000

Hi,
1.
>>>yeah, my first inkling was to symlink /etc/cron.daily but that breaks so much existing functionality.
I was actually thinking about /var/spool/cron/crontabs directory. You can put your cron definitions there in the old UNIX style. It works perfectly well and is more general and flexible then the /etc/cron.* files, I believe.
2.
>>>I followed you until you spoke of remote nodes? What exactly do you have in mind?
I implemented that approach in my old failover scripts for Digital/Compaq/HP TruCluster. Attached is a README file for this functionality. This will give you the concepts, although there are bits there that are TruCluster specific like CDSLs. If you are interested I am happy to share the scripts from which you can extract the relevant code and modify it for your needs.
Regards,
Chris
--------------
#
#
# Crontab file management.
# ------------------------
#
# There is a need for having a schedule of commands for cron
# that is active on a node only when the service is running
# on this node.
# In other words, certain commands must be scheduled only
# when the service is running and only on the node on which
# the service is running.
#
# One way to implement it would be to modify every such command
# to check for the presence of the service on the node on which
# the command is run. This will be quite cumbersome if there
# is large number of such commands.
#
# Another way to achieve execution of commands dependent
# on presence of a service would be by writing a jacket script
# taking as arguments the name of service in question and the
# pathname of the script to be executed and its arguments.
#
# The implementation here takes advantage of the fact that service
# specific cron processing is commonly done by a certain user or users
# and that crontab(1) maintains a separate configuration file for each
# user. Thus, it is relatively easy to manipulate the crontab file
# of such a user.
#
# A directory is chosen eg. /usr/local/crontabs.
#
# This directory contains templates of crontab files for users that
# are associated with certain services in a sense that the cron jobs
# for such a user are to be run only on the node on which this service
# is running.
#
# The script starting the service will install the template as the
# crontab file for such a user on startup of the service.
#
# The template of the crontab file should be named by the username
# with the extension service_on.
#
# Eg. for a user "fred" and chosen extension ".service_on" the template
# should be named:
#
# fred.service_on
#
# Typically, by convention, the name of the CAA application resource
# will be used as the "service" string in the extension.
#
# The contents of the template will be active on the member running
# the service for the lifetime of the service.
#
# On a graceful shutdown of the service the script will install
# another template of the crontab file for the user.
#
# This template of the crontab file should be named by the username
# with a predefined extension.
#
# Eg. for a user "fred" and chosen extension ".service_off" the template
# should be named:
#
# fred.service_off
#
# Typically, by convention, the name of the CAA application resource
# will be used as the "service" string in the extension.
#
# The contents of the template will be active on every member not running
# the service at the time.
#
# This template specifies periodically scheduled processing for a user
# on members that do not run the service at the time.
# The file may of course contain no commands, but it should exist.
#
# Of course both of those templates should be in the standard crontab(1)
# format.
#
# Notes and assumptions:
#
# 1.
# Please note that the above mechanism of crontab file management
# assumes that a user is associated with only one service.
# More state would need to be kept if a user would need different
# processing depending on whether 0, 1, 2 or more services were
# running on a node.
#
# 2.
# Please note that /var/spool/cron is a CDSL in the TCS cluster and thus
# all crontab files in /var/spool/cron/crontabs are node specific.
#
# 3.
# If a node dies suddenly and then reboots, then it will reboot
# with a set of crontabs that may not reflect the current state
# of services on the node after reboot.
# In fact the node will have all the crontabs from the moment it
# crashed augmented by changes caused by any sevices restarted
# on it after its reboot.
#
# What is really needed is another script - run on boot from
# /sbin/rc2.d directory that will install correct initial, inactive
# (*.service_off) versions of the crontabs on boot.
#
# 4.
# The crontab templates must be readable by the user for whom
# they are to be installed.
-----Original Message-----
From: linux-cluster-bounces redhat com [mailto:linux-cluster-bounces redhat com] On Behalf Of Joseph L. Casale
Sent: Wednesday, 31 March 2010 09:42
To: 'linux clustering'
Subject: Re: [Linux-cluster] Cron Jobs
>1.
>What about replacing the directory containing the cron job descriptions in /var with a symbolic link to a directory on the sahred filesystem.
yeah, my first inkling was to symlink /etc/cron.daily but that breaks so much existing functionality.
>2.
>You application service start/stop script may modify the cron job description files. This is more complex, as it has to deal with remote nodes that may be >down.
I followed you until you spoke of remote nodes? What exactly do you have in mind?
Thanks!
jlc
--
Linux-cluster mailing list
Linux-cluster redhat com
https://www.redhat.com/mailman/listinfo/linux-cluster