PIKT Logo PIKT

Introduction: Scheduling a Process

PIKT Tip Jar
PIKT is user-supported software. 
Please show your support.
 
Home
News
Introduction
Samples
Tutorial
Reference
Software
Authors
Licensing



Forum
Marketplace
Links
SiteSearch
FAQ
Contribute
Donate
ContactUs



Google
Web pikt.org


Scheduling a Process

Perhaps the biggest problems with cron are that, in order to manage it, you have to do it one system at a time, and interactively.  PIKT offers a centrally managed, convenient-to-use, and options-rich alternative process scheduler.

Suppose you have a special security-related program or script, "watchdog.py", that you wish to run from time to time on all systems.  You might schedule its execution in the piktmaster's alerts.cfg file this way:

	Watchdog

	timing          15 0-23/4 * * *

	execcmd         "/usr/local/bin/watchdog.py"
	
You would schedule this script on all systems using the command:
	# piktc -ierv +S Watchdog +H all        [or: ... -H downsys]
	
This would install (due to the piktc 'i' option) a short Watchdog.alt script on the slave systems:
	Watchdog
	        exec "/usr/local/bin/watchdog.py"
	
add this line to the slave systems' piktd.conf (the piktc 'e', "enable", option):
	15 0-23/4 * * * /pikt/bin/pikt +S Watchdog
	
and restart the piktd daemon (the 'r' option; 'v' says to be verbose).

This would have the slave system piktd run the Watchdog script, hence the watchdog.py program, every four hours at 15 minutes after the hour, much as cron would.  Like cron, PIKT would log the script run, in PIKT's case in the piktd.log:

	May  6 11:56:00 ottawa piktd[16129]: [ID 1 INFO] /pikt/bin/pikt +S Watchdog
	
Suppose you need to run watchdog.py more often on some systems, less often on others.  Under extraordinary circumstances, suppose you want to run watchdog.py hourly.  You might specify this:
	Watchdog

	#ifdef paranoid
	timing          15 * * * *
	#elsedef
	#  if misscritsys
	timing          15 0-23/2 * * *
	#  else
	timing          15 0-23/4 * * *
	#  endif
	#endifdef

	execcmd         "/usr/local/bin/watchdog.py"
	
If we are in so-called "paranoid" mode, we have piktd run watchdog.py on all systems 15 minutes after every hour.  Otherwise (in normal security mode), run it at 15 minutes after the hour every two hours on mission-critical systems, and 15 minutes after the hour every four hours only on all other systems.

Given watchdog.py's security function, one problem with these schedulings could be their predictability--in all cases, at 15 minutes after the hour.  What if we want to add some unpredictability to the scheduling?  We might do this:

	timing          15 0-23/4 * * *
	drift		10
	
which is equivalent to this (adding drift as a sixth field):
	timing          15 * * * * 10
	
This tells piktd to run watchdog.py at 15 minutes after every hour give or take 10 minutes--that is, randomly as early as 5 minutes after the hour to as late as 25 minutes after the hour.

Or we might add unpredictability this way:

	timing          15 50% * * *
	
This tells piktd to run watchdog.py 15 minutes after the hour with just a 50% chance for any particular hour--that is, on average every two hours.  We could also add drift to the mix:
	timing          15 50% * * * 10
	
This directs piktd to run the script anywhere from 5 to 25 minutes after the hour, on average every two hours.  Note that, depending on luck, the script might run (with a random 20-minute drift) hour after hour without break, then not run at all until hours later when the luck changes.

Suppose we want to run this script (conditionally, with drift) at (un)certain times during the day, at other times during the night, and at still other times during the weekend.  We might do:

	timing          15 6-21      * * 1-5 10  // mon-fri,  day  hrs
	                15 6-21/2    * * 0,6 10  // sun,sat,  day  hrs
			15 0-5,22-23 * * *   20  // each day, nite hrs
	
These lines would appear in piktd.conf:
	15 6-21 * * 1-5 10 /pikt/bin/pikt +S Watchdog
	15 6-21/2 * * 0,6 10 /pikt/bin/pikt +S Watchdog
	15 0-5,22-23 * * * 20 /pikt/bin/pikt +S Watchdog
	
Suppose watchdog.py calls for optional human (sysadmin) intervention, but it's a holiday weekend, and we are lightly staffed.  We might run the script less frequently on holiday weekends with this:
	#ifndef holiday
	timing          15 6-21      * * 1-5 10  // mon-fri,  day  hrs
	                15 6-21/2    * * 0,6 10  // sun,sat,  day  hrs
			15 0-5,22-23 * * *   20  // each day, nite hrs
	#elsedef
	timing          15 6,18      * * *   10  // holiday, at 6 am and 6 pm
	#endifdef
	
(We would have other vital scripts and alerts run unchanged, whether a holiday or not.)

What if we need to debug the watchdog.py script and have it specially run more often in test mode?  We might do this:

	#ifndef test
	#  ifndef holiday
	timing          15 6-21      * * 1-5 10  // mon-fri,  day  hrs
	                15 6-21/2    * * 0,6 10  // sun,sat,  day  hrs
			15 0-5,22-23 * * *   20  // each day, nite hrs
	#  elsedef
	timing          15 6,18      * * *   10  // holiday, at 6 am and 6 pm
	#  endifdef
	#elsedef
	timing          0,15,30,45 * * * * // testing, every 15 mins, no drift
	#endifdef
	
As another example, and admittedly a very complex (and artificial) one, now add per-machine differences back into the mix:
	Watchdog

	#ifndef test
	#  ifndef holiday
	#    if misscritsys
	timing          15 6-21      * * 1-5 10  // mon-fri,  day  hrs
	                15 6-21/2    * * 0,6 10  // sun,sat,  day  hrs
			15 0-5,22-23 * * *   20  // each day, nite hrs
	#    else
	timing          15 6-21/3    * * 1-5 10  // mon-fri,  day  hrs
	                15 6-21/6    * * 0,6 10  // sun,sat,  day  hrs
	#    endif
	#  elsedef
	#    if misscritsys
	timing          15 6-21      * * 1-5 10  // mon-fri,  day  hrs
	                15 6-21/2    * * 0,6 10  // sun,sat,  day  hrs
			15 0-5,22-23 * * *   20  // each day, nite hrs
	#    else
	timing          15 6,18 * * *  10  // holiday,  at 6 am and 6 pm
	#    endif
	#  endifdef
	#elsedef
	timing          0,15,30,45 * * * * // testing, every 15 mins, no drift
	#endifdef

	nice            10

	execcmd         "/usr/local/bin/watchdog.py"
	
Several things to note:  For the mission-critical systems, they run watchdog.py under the same schedule, holiday or not.  If it's not a holiday, and for the non mission-critical systems, we don't run watchdog.py at night.  Testing mode runs according to the same predictable schedule (is unaffected by the system, the time of day, the day of the year, etc.).  And notice that we have told Unix/Linux to "nice" the watchdog.py run.  (That is, give it a higher or lower priority.  Needless to say, we can apply all sorts of #if and #ifdef logic to the 'nice' statement as well.)

Whew!  Is this potentially complicated or what?  Of course, if you don't need all this sophisticated complexity, keep it simple.  (Review the very first bare-bones timing example above.)  On the other hand (mode, system, day of the week, ...), if you want to fine-tune your process schedulings, PIKT gives you the power to do that.

Since PIKT is very flexible with its layout, you can add extra spaces, indentations, blank lines, comments--whatever you need to make your complicated specifications visually clearer.

You could also hide away some of the complexity using PIKT macros and #include files, for example:

	Watchdog

	#ifndef test  // we're not testing

	#    ifndef holiday  // it's not a holiday

	#        if misscritsys
	#            include <alerts/watchdog_misscritsys_timings_alerts.cfg>
	#        else
	#            include <alerts/watchdog_timings_alerts.cfg>
	#        endif

	#    elsedef         // it is a holiday

	#        if misscritsys
	#            include <alerts/watchdog_misscritsys_timings_alerts.cfg>
	#        else
	timing          =watchdog_timings_holiday
	#        endif

	#    endifdef        // holiday

	#elsedef      // we're testing

	timing          =timings_test_every_15_minutes

	#endifdef     // test

	nice            =watchdog_nice

	execcmd         =watchdog
	
We won't show you the #include file contents or the macro definitions.  Just use your imagination.

It bears repeating:  With PIKT, with timing specifications as with everything else, be as complicated as you like, or keep things simple.  You have the utmost power and flexibility.  All choices are entirely yours.

All complexity aside, let's not overlook:  You manage all of this complexity in a single config file (alerts.cfg) on a single machine (the piktmaster).  As complicated as you might make your central PIKT configuration, you no longer have to be bewildered by the vast array of crontab files, with all their many differences (some intended, in many cases not) scattered hither and yon across all of your many systems.

Equally important, you can reconfigure and reschedule across dozens or hundreds of systems with just a few quick edits and a piktc command or two.  (When you change a timing specification in alerts.cfg, you need to register that change with a 'piktc -er' command.)  You no longer have to spend hours and hours logging into systems to edit the crontab (and perhaps restart the crond) one file and one system at a time.  Hooray!



Home | News | Introduction | Samples | Tutorial | Reference | Software | Authors | Licensing
Forum | Marketplace | Links | SiteSearch | FAQ | Contribute | Donate | ContactUs
Top of Page

Join pikt-users, pikt-workers, and/or the PIKT Forum. 
Open Hand Please visit our sponsors.

Page best viewed at 1024x768.   Page last updated 2005-01-09.
This site is PIKT® powered.
PIKT® is a registered trademark of the University of Chicago.
Copyright © 1998-2005 Robert Osterlund.  All rights reserved.