Crontab - doing things periodically

X-Git-Url: http://gb7djk.dxcluster.net/gitweb/gitweb.cgi?a=blobdiff_plain;f=html%2Fcron.html;fp=html%2Fcron.html;h=adb9320ace09d7912c189db7ff1b7bfefe16bc2b;hb=f3adc82a0299652d929b73c718127fa38571eec5;hp=0000000000000000000000000000000000000000;hpb=69003f56e5249357c746999c2feec5f44c258472;p=spider.git diff --git a/html/cron.html b/html/cron.html new file mode 100644 index 00000000..adb9320a --- /dev/null +++ b/html/cron.html @@ -0,0 +1,151 @@ + + + + Crontab - doing things periodically + + + + + + + + + +

Crontab - doing things periodically

+ + + +

Dirk Koopman G1TLH

+ + +Last modified: Mon Dec 28 01:06:43 GMT 1998 + +

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")
+

+ + It is important remember that these crontab routines execute in line with the main + cluster code, so if you create a long, slow crontab commands, 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. +

+ +

Caveats

+ + There seems to be an intermittent problem when running + (especially?) with the debugger on. Essentially you will + experience random crashes with nonsensical error messages. I + believe that this is caused by stack tracing trying to work inside + forked processes. + + +

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)