|
Re: script suicide?
by bobn (Chaplain) on Jul 21, 2003 at 01:09 UTC
|
perldoc -f alarm
Alarm allows a program to set a timer, at the expiration of which, a SIGALRM is sent to the program.
By eval'ing a block that includes re-assignment of the $SIG{ALRM} handler, then setting the alarm, the block can be made to exit if the timer expires before the block finishes normally. Examining $@ allows you to ensure that the block died for the expected reason. Very useful for anything that interacts over the network.
I think a process can only have one alarm running at a time, so if any of your routines or modules you're use'ing uses it already, you may be out of luck. But if the module is using alarm, it should be doing so to implment a timeout of it's own, so the trick is to make it timeout the way you want it to.
--Bob Niederman, http://bob-n.com
| [reply] |
|
|
| [reply] |
|
|
<plug> If you'd like to be able to have multiple alarms running, without affecting (or being affected by) other code you use which sets alarms, you could use the :OVERRIDE option of Alarm::Concurrent. One should be wary of using this option in production level code, as it overrides %SIG, but the OP's situation doesn't seem like it would be a problem. And, of course, this is just a standard warning, as I've never actually had it cause a problem for me.
bbfu
Black flowers blossom
Fearless on my breath
| [reply]
[d/l] |
Re: script suicide?
by dws (Chancellor) on Jul 21, 2003 at 04:42 UTC
|
The script has loops, so dumping out checkpoints to see where it is snagging up is a real hassle ... it generates a lot of output with the loops
So write a script to analyze the log. Looking in logfiles for evidence of accidental loops isn't rocket science. If you follow a bit of discipline in how you format your log entries, parsing them should be straightforward.
| [reply] |
Re: script suicide?
by Abigail-II (Bishop) on Jul 21, 2003 at 07:43 UTC
|
To have a script kill itself after 30 seconds:
$SIG {ALRM} = sub {exit};
alarm (30);
There's however one caveat: if you use Perl 5.8.0, and your
script is "hanging" during a Perl operation, the signal
will be queued until that Perl operation is finished.
Abigail | [reply]
[d/l] |
|
|
But then you can get the "old" dangerous pre 5.8.0 signal handling back by using POSIX::sigaction. YMMV.
Liz
| [reply] |
|
|
Hmm, trying this in a small test script didn't seem to work. Which means I'm probably not doing it right.
The code below would make me think that it will print that out for 5 seconds and then stop via the exit call.
Instead it just runs and runs, happy as can be.
$SIG {ALRM} = sub {exit};
alarm (5);
while(1){
print "hairy fishnuts\n";
}
"perl -v" tells me "This is perl, v5.6.1 built for i386-freebsd"
What am I doing wrong?
-------------------------------------------------------------------
There are some odd things afoot now, in the Villa Straylight. | [reply]
[d/l] |
|
|
You either have a bug in your particular installation
of Perl, or in the OS (I tried it with the same version
of Perl, but different OS), or you aren't patient enough.
Did you by any chance run this without redirecting
standard output? Then it might take more seconds, and
if you do this remotely, and have a slow network, it
even takes more time. For me, the program gets aborted
after 5 seconds if I redirect output - but it takes 8
seconds before getting a prompt if I don't redirect output.
With a slow network, or a slow terminal, it might take minutes.
Abigail
| [reply] |
|
|
Re: script suicide?
by hatter (Pilgrim) on Jul 21, 2003 at 11:26 UTC
|
I suspect the shared hosting you had used rlimit or ulimit to set the resources available to a process - for CGI scripts, this can be set with the RLimit* directives in apache, for system commands such as your cron jobs, have a poke around the various manpages for ulimit/rlimit/setrlimit/etc The correct or most appropriate ones depend on which OS and version you're running.
A quick flick through CPAN finds the psh perl shell has a ulimit function, but nothing much else. You might want to look in closer detail at the Proc:: hierarchy in case there's something useful hidden in there, if you'd rather do it within the script rather than in the shell that calls the script.
the hatter
| [reply]
[d/l] |