Use alarm within your script to schedule a signal, and have your $SIG{ALRM} handler clean up and exit gracefully.

$SIG{ALRM} = sub { exit; };

alarm 60 * 60 * 2;
[download]

Another option is to have your script write a pid file out someplace:

open(F, ">$wherever/myscript.pid") or warn "myscript.pid: $!\n";
print F "$$\n";
close(F);

$SIG{TERM} = sub { exit; };

END {
   unlink "$wherever/myscript.pid";
}
[download]

And then script something like this in cron:

[ -r $wherever/myscript.pid ] && kill `cat $wherever/myscript.pid`
[download]

Schedule it to start at some time say 1:30pm with a cron entry like the following:

13 30 * * * /path/to/myscript.pl
[download]

Have the program print the pid (available in perl as the var $$) to a file like /tmp/myscript.pid and add a second line to cron like:

15 30 * * * kill `cat /tmp/myscript.pid`
[download]

In case you were not aware you edit cron with the command crontab -e. See man crontab for more details.

-monkfish (The Fishy Monk)

An important administration sanity tip.

You don't want to edit crons with crontab -e. If someone messes up your cron, you really, really, really need to be able to fix it.

Instead do:

crontab cron.ctl
[download]

where cron.ctl is a file you have in a revision control system. Make all edits through editing cron.ctl then reloading the cron.

I've found that a daily snapshot of current crontabs (in /var/spool/cron/$USER on my linux machine) works fine. Either an automatic cvs check in, or just a tar.gz of modified crontabs. I don't necessarily need an archive of each minor edit made to a crontab during the day, but rolling it back to "the way it worked yesterday" is oft requested.

Behind the scenes, crontab -e really just automates these two steps:

vi $DefaultCrontabFile;       # use your $EDITOR to edit default file
crontab $DefaultCrontabFile;  # install said file
[download]

-Blake

If it's in a loop, can't you do this?

my $start = time();
while( time() <= $start + 7200 ) {
  ....sutff....
}
[download]

granted, it consumes some cycles... I'm just weary of using SIGALRM and such. Take it as a TMTOWTDI :-)

Sidestepping the wisdom of time based loops.....

Your $start assignment is unnecessary. The special $^T variable already contains that information. (i.e. perl stores the time() value at startup in $^T) So, you could rewrite the above as:

while ( time-$^T <= 7200 ) {
  ....sutff....
}
[download]

Note: this is a mod_perl gotcha since the "startup" time could be a looong time ago. $^T is also the value used when the -M, -A, and -C filetest operators determine the relative age of a file. The age is relative to whatever happens to be in $^T, which has implications for any long running perl program.

-Blake

Well, it depends on the semantics of the code :-)

I *usually* want to have the loop to last for X amount of time, and not the script itself. That's where my

   my $start = time()
[download]

...comes in. And as you said, $^T is sometimes a problem. I like explicit-ness :-)

* 14-16/5 * * 1-5 your/command
[download]