- Get Stackato
- Why a Private PaaS?
- Features & Benefits
- Stackato by Language
- Compare Editions
- Stackato & Cloud Foundry
- Developer Tools
- Stackato Training
- Professional Services
- Commercial Support
- Code Recipes
Kevin "kj" Woolley, March 17, 2006
Yesterday I ran into an interesting problem that took me on a tour of the sources for PerlApp and an old version of Apache. It's perhaps more of an uncommon problem than what I cover here, but it'll come in...
Yesterday I ran into an interesting problem that took me on a tour of the sources for PerlApp and an old version of Apache. It's perhaps more of an uncommon problem than what I cover here, but it'll come in handy for those who run into it.
A user wrote in and related the following situation:
- CGI using interpreted Perl works great
- CGI using compiled C works just fine
- CGI using PerlApp-wrapped Perl dies with a 500 Internal Server Error
On the surface this looks annoying but innocuous. The environment is AIX 5, Apache 1.3.29, and PDK 6.0, which isn't a bad way to go by any means, but AIX has a few oddidities that can keep you on your toes.
The Apache configuration seemed pretty standard, and the .htaccess file the user provided didn't hold any surprises. The source code for the CGI was effectively nothing more than a few lines of test code -- the problem definitely wasn't there.
I had the user generate a ScriptLog, and among the output in the log was this little gem:
Panic: Cannot determine full path of 'foo'
In this case, 'foo' was the name I gave the compiled CGI script. At this point I had more questions than answers. Time to haul out the sources for PerlApp.
I had never checked out the sources for PerlApp before, but thanks to the PDK team's efforts to keep the codebase clean it didn't take me long to find where the error message was being generated. I expected PerlApp to try to find the path to the program via argv, and it does, so it seemed that argv was being set to just foo.
This didn't make a lot of sense. Apache not only knows the URI for the CGI script, it has to know the full path to it in order to execute it. Why wasn't that being used for argv? In crawling through mod_cgi.c, I noticed a handy ifdef, and rebuilt Apache with -DDEBUG_CGI. One quick './httpd -X' later, and I was in business -- and had it definitively from Apache that it was setting argv to only foo.
A quick chat with Jan Dubois turned up the solution pretty quickly -- add the directory containing the CGI to the PATH, which gets walked by PerlApp as a last resort if it can't find the full path of the program any other way. Inefficient, but effective. Sure enough, that solved the problem.
So why the war story, especially on a fairly easy problem? Two reasons. Firstly, to make sure there's some Google food on the topic. Secondly, to show the cooperation between users, developers and myself, and reiterate how important it is. Without that cooperation this could have taken a lot longer to figure out. Thirdly, to show that not every question that comes to us is one that we know the answer to. The only way to make sure it wasn't a bug in PerlApp was to track down the reason why it was happening.
This story displays many of the elements of solving a new problem for a user:
- Get a problem report and description of the problem.
- Get information on the environment in which the problem happens.
- Reproduce the problem.
- Consult the developers if the ideal solution is ambiguous or not immediately apparent.
- Solve the problem in a test case (reproduction to fixed).
- Relay information on the solution to the user.
- Document the problem and its solution.
That's part of what I do here -- and it's fun.