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@xxxxxxxxxx [mailto:linux-cluster-bounces@xxxxxxxxxx] On Behalf Of Joseph L. Casale Sent: Wednesday, 31 March 2010 09:42 To: 'linux clustering' Subject: Re: 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
