Capture DIE statments from Perl

[Tookelso]

Hello,

I have perl scripts which are run on servers other than our own.

I can't see the console output on those servers. The feedback I get is
via logfile.

If my script dies unexpectedly, it is very difficult to find what
caused it to die.

Example:
use strict;
use warnings;
some_undefined_sub();

In the example above, Perl compiles OK, but when I run this script,
Perl dies with "Undefined subroutine blah blah".

Since I can't see the console output on the remote machine, I can't see
what went wrong.

I could divert STDERR to a file, but our scripts run for long time
periods. The log files are on a network, and it's possible that if a
network glitch occurs, I still may never see my error messages.
There's documented issues with write buffers not being flushed
immediately on Windoze boxes.

Any other advice?

Thanks,
--Took

 

[David Squire]

(e-mail address removed) wrote:

[snip]

I could divert STDERR to a file, but our scripts run for long time
periods. The log files are on a network, and it's possible that if a
network glitch occurs, I still may never see my error messages.
There's documented issues with write buffers not being flushed
immediately on Windoze boxes.

Any other advice?

If you can't test your scripts locally (if not, why?), and you don't
have access to the error log (not access log) on the server, I would
suggest sacking your boss. That is an unworkable situation.

DS

 

[Tookelso]

If you can't test your scripts locally (if not, why?), and you don't

have access to the error log (not access log) on the server, I would
suggest sacking your boss. That is an unworkable situation.

I *do* have access to the error log that my program opens and prints
to. It's a simple text file. I don't know what you mean by "access
log".

I want any warning or DIE statement by my program to be printed to my
log file, instead of the console/screen.

I don't want to re-route STDERR for the entire duration of the program.

I just remembered the Camel book chapter about Signals.

I'm going to try using $SIG{__DIE__} and $SIG{__WARN__} to trap these
errors, print them, then exit the program.

Does anyone have any gotchas that I need to watch out for? Is this the
best solution?

Thanks in advance,

--Took

 

[xhoster]

I *do* have access to the error log that my program opens and prints
to. It's a simple text file. I don't know what you mean by "access
log".

httpd servers keep access-logs and error-logs. It doesn't sound like you
are using CGI, but experience leads most people here to just assume that
clueless posters are using CGI.

I want any warning or DIE statement by my program to be printed to my
log file, instead of the console/screen.

I don't want to re-route STDERR for the entire duration of the program.

I just remembered the Camel book chapter about Signals.

I'm going to try using $SIG{__DIE__} and $SIG{__WARN__} to trap these
errors, print them, then exit the program.

Does anyone have any gotchas that I need to watch out for? Is this the
best solution?

No, the best solution is the one you ruled out for no apparent reason.

If you want to capture STDERR in a file, then capture STDERR in a file.
If your program prints things to STDERR that don't belong there, then
change the program so it doesn't do that.

Xho

 

[Tookelso]

Thanks for the replies--I'll definitely look at using Log:ispatch.
I've been looking for a logger that you can turn up/down depending on
if you're in development or production.

Just to clarify, I *do* wish to log my errors to a file.

Here's a sample current script:
# Some::Module can DIE if it can't initialize.
# These DIE messages go to the console on the remote server.
# The messages then are pushed off the remote console's buffer by
# other processes.
use Some::Module;
my $something = Some::Module->new();

I'm a programmer by profession, but the people writing these scripts
are *not* avid programmers, and when their script doesn't even produce
a log file, they're left in limbo.

Yes, I can eval{} a lot of things, and I will definitely do this. But
when the pseudo-developers are testing their stuff, they don't always
do this.

If every script has the following line at the top:

$SIG{__DIE__} = sub { # print error to some logfile };

Then wouldn't that suffice for trapping any error?

New scripts would look like this:
# Now, if new() blows, then it will be logged.
$SIG{__DIE__} = sub { # print error to some logfile };
use Some::Module;
my $something = Some::Module->new();

Wouldn't that suffice?

What is the disadvantage to doing this, vs. overriding Perl's
CORE::GLOBAL::die like the previous poster suggests in the snippet
below?
<snip>

Is it because of the "arguably broken state of $SIG{__DIE__} mentioned
here?
http://perldoc.perl.org/functions/eval.html

Thanks,

--Took