Crontab - doing things periodically

Last modified: Fri Jan 19 14:25:13 GMT 2001

Introduction

There are a number of jobs that need to be done periodically. The principle one being starting connections to other clusters if you are not connected. The crontab allows you to do this.

Location

There two locations for the crontab files. The first and standard one (which in common with other 'issue' files should not be changed) lives at /spider/cmd/crontab. The sysop changable one lives at /spider/local_cmd/crontab.

The files will automatically be re-read whenever you change them.

The `Crontab` File

The crontab file defines what is to be done and when. It consists of lines of text created by your favorite editor. Completely blank lines or lines starting with '#' are ignored.

Each line of a crontab file contains six fields each separated with white space. The first five fields are times when the command is to be executed and the last field is the command itself. The time fields consist of:-

field Allowed Values

minute 0 - 59

hour 0 - 23

day of month 1 - 31

month 1 - 12

day of week 0 - 6 (0 is Sunday)

A field may be '*', which means 'any when' for that field.

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen. The specified range is inclusive. For example, 8-11 for an hours entry specifies execution at hours 8, 9, 10 and 11.

Lists are allowed. A list is a set of numbers (or ranges) separated by commas. Examples: 1,2,5,9 or 0-3,5,8-12.

Commands are actually small snippets of perl. They can be anything legal within perl and the context of the DXSpider cluster.pl daemon. The normal use will be connecting to another cluster and a set of routines are specially provided in the context of the DXCron package to make this easy. For example

  start_connect('gb7tlh') if !connected('gb7tlh')

will attempt to start a connection process to GB7TLH if it isn't already locally connected.

There is absolutely no reason why you could not do something more complicated using information contained inside the DXSpider daemon, but this will obviously require a more complex line of code. You can also write your own functions, include them within the DXSpider system and call them from the crontab

A full crontab file could like like:-

  #
  # This is a sample crontab file 
  #
  #
  # check every 10 minutes to see if gb7tlh is connected and if not
  # start a connect job going

  0,10,20,30,40,50 * * * * start_connect('gb7tlh') if !connected('gb7tlh')

  # at 03:15 on Sundays start a job called 'analyse.pl' which does something
  # or other. This starts a new process and runs to completion, be careful
  # what you do with stdin and stdout as they are the same as those of
  # cluster.pl 

  15 3 * * 0 spawn('/spider/local/analyse.pl')

  # this is a pointless command which will echo the string shown
  # on the same terminal as the cluster.pl program after substituting
  # the values for mycall and version
 
  15,30 * * * spawn("echo $main::mycall is a DXSpider Version $main::version DX Cluster system")

  # then there is always the highly contentious one like this little jem which
  # checks every hour to see if a certain callsign is connected to another cluster
  # and silently disconnects him. This is an example only (of course...)
  
  23 * * * * rcmd('rcmd/gb7dxm disc/noinform G9TLH') if present_on('G9TLH', 'GB7DXM')

It is important remember that these crontab routines execute in line with the main cluster code, so if you create a long, slow crontab command, it will impact on the speed and usability of the cluster as a whole.

Standard Routines

As mentioned earlier, there are a small number of routines that are declared in DXCron context. They are there basically to make the starting of connections and external programs easy. They are:-

connected(<callsign>) - returns true if the <callsign> is directly connected to this cluster node.
start_connect(<script-name>) - starts a connection script just as if you had typed in connect script-name on the sysop console client.
spawn(<command>) - start a <command> as a new process. This is used to do various batch jobs that you may wish to happen at certain times of the day or week that operate on your machine but don't require access to the real-time internals of the cluster daemon. You can execute just about any command you like, but be warned stdin and stdout are still connected to the same terminal (if any) as the cluster daemon. Any unix command and arguments can used, see exec in the perl documentation.
disconnect(<callsign>) - disconnects a locally connected station from your node.
rcmd(<node-call>, <command>) - send a command to another node in exactly the same way as, for example, RCMD/GB7TLH disc GB7DJK typed on a sysop console.
present(<exact-callsign>) and presentish(<callsign-no-ssid>) - returns true if the callsign is connected anywhere on the cluster either with the exact callsign or with the callsign minus its ssid respectively.
present_on(<exact-callsign>, <node>) and presentish_on(<callsign-no-ssid>, <node>) - returns true if the callsign is connected on the node specified either with the exact callsign or with the callsign minus its ssid respectively.
last_connect(<callsign>) - Returns the last connect time of the callsign or the current time if it is currently connected locally.

Caveats

There was an intermittent problem when running (especially?) with the debugger on. Essentially you would experience random crashes with nonsensical error messages returning from funny places on the stack (if the debugger was on) or just core dumping (if it wasn't).

I believe this now to be fixed. YMMV, if so tell me about it!

field	Allowed Values
minute	0 - 59
hour	0 - 23
day of month	1 - 31
month	1 - 12
day of week	0 - 6 (0 is Sunday)