Re: Help with a stragegy for diagnosis
- From: Bruce Van Allen <bva@xxxxxxxxxx>
- Date: Sat, 3 Mar 2007 10:26:40 -0800
On 3/3/07 Malcolm Hoar wrote:
FreeBSD 4.7-RELEASE
Apache 1.3.37
Perl 5.8.4
I have a Perl CGI that has work for years. However,
in the last 24 hours, it has failed two times. It
worked before the first failure. It worked after the
first failure and before the second. It has worked
after the second.
When it failed... it was trying to create (and open
for writing) a simple ASCII file. Fortunately, I did
include code to check for errors on the open(). That
code was executed and did successfully append an
error record to a different log file. Here's the
salient code:
...
Since my error detection and logging is apparently
working, I do have the opportunity to try and
capture/log some other system information if/when
the error arises again. But what data? I can't think
of much that makes sense or would be likely to help.
More information is needed. How are you finding out about the errors?
How comfortable are you with Perl debugging?
As a start, if your WebError subroutine doesn't already do this, try
using CGI::Carp to get more verbose and safer errors and warnings. If
it's OK to expose the errors to users,
use CGI::Carp qw/fatalsToBrowser/;
Otherwise put a carp log file somewhere,
use CGI::Carp qw/carpout/;
open (LOG, ">>var/tmp/mycgi-log")
or die "Can't append to mycgi-log: $1\n";
carpout(*LOG);
[examples from the Camel, 3rd ed., paperback, page 879]
A strategy would be to write tests for the script until you get the same
error, fix the script so those tests pass, then write more tests and
repeat until you can't get that error.
If possible, take your script out of the CGI execution environment, set
it up run in a local shell, and then write tests. If you leave it in
place, you could write a Perl script with the CPAN LWP modules to create
a user agent to send automated calls to your CGI. But remember that your
tests should be failing a lot at first, so use some caution if the CGI
is on someone else's server...
With CGIs I would start with the script's input, including config info.
Test for correct and incorrect user input, speed and sequence of input,
repetition of input, and so on.
Here are some other lines to explore:
* Are you checking for errors when closing files? Maybe something
happened just before the error you're seeing.
* How are these files used by this or any other script once they're
created?
* Disk near full?
$file = $txdir . $sequence;* Where do the components of the filename come from? Are they
sanity-checked? Does the error message have the expected path for the
file? Could the name have already been in use?
* What permissions would the file be assigned when things work
correctly?
* Does your script or any other modify the directory holding these
files? How many files are in the directory? Does any process clear out
obsolete files?
* Are you logging only errors, or do you also have a way to trace
patterns in normal ops?
* Could you or someone else have been doing maintenance on the server
when the errors occurred?
* Perl version 5.8.4 didn't stay current very long -- you might want to
check for clues in the version history changes, or just upgrade to 5.8.6
or 5.8.8 if that's under your control. Could you locate the script on a
different server and test it there?
* Speaking of versions, the usage
&WebError (...)
suggests Perl 4 legacy code (or maybe a Perl 4 legacy coder -- greetings
comrade!); there might be some other archaism that's causing problems.
* Could the users getting the errors have done something unexpected with
their Web browser Reload or Back commands, or with bookmarks set for
script-generated "pages" from previous visits to your site?
* Were the two errors experienced by the same user?
Good luck!
- Bruce
__bruce__van_allen__santa_cruz__ca__
.
- Follow-Ups:
- Re: Help with a stragegy for diagnosis
- From: Malcolm Hoar
- Re: Help with a stragegy for diagnosis
- References:
- Help with a stragegy for diagnosis
- From: Malcolm Hoar
- Help with a stragegy for diagnosis
- Prev by Date: Re: Help with a stragegy for diagnosis
- Next by Date: Re: Help with a stragegy for diagnosis
- Previous by thread: Re: Help with a stragegy for diagnosis
- Next by thread: Re: Help with a stragegy for diagnosis
- Index(es):
Relevant Pages
|
