Look at the Time::Limit module. It terminates the script after a given time. In your case, the usage would be:

use Time::Limit '86400.0'; # terminate after 86400 seconds (24h)
[download]

Could be just the thing you need.

Looking at this.. My concern is what the exit code would be on self termination. If non zero, the automated scheduling system will flag this as a job failure which is not the intention.

Time::Limit sends the process a SIGTERM, which you can catch.The following exits with a zero exit code after 5 seconds:

use Time::Limit -quiet, '5';

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

while(1) {}
[download]

Some notable things about alarm:

Only one timer may be counting at once. Each call disables the previous timer

It is usually a mistake to intermix alarm and sleep calls, because sleep may be internally implemented on your system with alarm.

If you want to use alarm to time out a system call you need to use an eval/die pair. ... caveats given in Signals in perlipc.

Portability issues: alarm in perlport.

If this is *NIX, another way to do it might be to arrange for cron to call killall (or kill if you know the PID; e.g. your script could write it to a file at a known location) at 11:30 the next day, and set up a %SIG handler for that signal in your script for a graceful exit.

If this is *NIX, be very, very careful before you type the word "killall" into your terminal session. Or arrange for cron to call it. On traditional UNIX systems, AIX in particular, it kills all processes except the one calling killall. Kills as in 'SIGKILL', not 'SIGTERM'. Be very, very careful.

A safer way would be to set up an 'at' job calling 'kill' with the PID of the running process, at the beginning of the script. Or just use Time::Limit. :)

- Luke

Using at or cron is not an option. We are mandated to use the corporate approved scheduling system. The goal is to run the process right up until the next 'build' of the daily schedule. Failure to terminate gracefully prior to the next schedule build means I would have a growing number of the same process running which is less than ideal.