GoDaddy 500 Error

I had a Perl CGI file that I wanted to put on my website, but I can't
seem to get it to work properly, and I can't find a straight solution
to this anywhere.  I keep getting a 500 Internal Server Error when I
try to run it.  I called GoDaddy tech support and they didn't tell me
anything helpful short of that it should work...

What I've tried so far:

I've turned the file into a hello world script so I know it SHOULD
work.  I've tried sending fatals to the browser, which gave me the same
500 error.  I've tried changing the permissions to 755, and the result
was the same.

I'm pretty much out of ideas at this point.  Can anyone please point me
in the right direction?  This is really annoying, since I decided to
pay extra for the hosting account just for the CGI support.  It's times
like these I wish my ISP still let me host on my own computer...

Adam Polt wrote:
> I had a Perl CGI file that I wanted to put on my website, but I can't
> seem to get it to work properly, and I can't find a straight solution
> to this anywhere.  I keep getting a 500 Internal Server Error when I
> try to run it.

If you have access to the server logs, look at the server logs to find
out what the "real" error message is.

> What I've tried so far:
>
> I've turned the file into a hello world script so I know it SHOULD
> work.

That doesn't tell us anything.  You're asking us to take your word that
you correctly wrote a Hello World CGI script.  Post the actual code.

> I've tried sending fatals to the browser, which gave me the same
> 500 error.

*IF* you used CGI::Carp correctly, then this most likely means that the
CGI script failed to execute before the Perl interpreter ever got to
it.

>  I've tried changing the permissions to 755, and the result
> was the same.

Changed them *from* what to 755?  Why are you assuming this is correct?
I know nothing about GoDaddy's hosting policies, but do they at least
tell you somewhere what permissions should be?  Do you know for a fact
that there webserver isn't configured to prevent scripts with group &
world read permissions from executing?

> I'm pretty much out of ideas at this point.  Can anyone please point me
> in the right direction?

We could, but you haven't given enough information to enable us to do
so.

> This is really annoying, since I decided to
> pay extra for the hosting account just for the CGI support.

You paid extra at the hosting service that very proudly advertises
itself as the cheapest host available.  I'm sorry to be blunt, but you
get what you pay for.

Paul Lalli

Paul Lalli wrote:
> Adam Polt wrote: 
>
> If you have access to the server logs, look at the server logs to find
> out what the "real" error message is.
>
[snip]
> 
>
> *IF* you used CGI::Carp correctly, then this most likely means that the
> CGI script failed to execute before the Perl interpreter ever got to
> it.
>

I don't think it is possible to view the server logs (without contacting
GoDaddy). Also, if I remember correctly, use CGI::Carp
qw(fatalsToBrowser); has no effect on their servers.

[snip]

> 
>
> You paid extra at the hosting service that very proudly advertises
> itself as the cheapest host available.  I'm sorry to be blunt, but you
> get what you pay for.
>

Well said :-) GoDaddy seems to configure their servers in a way that
makes running anything but basic scripts almost impossible. Take a look
at Hostgator.com ... every company has its issues, but at least their
servers work as expected ;-)

Thanks,
Eric

Eric Martin wrote:

> Also, if I remember correctly, use CGI::Carp
> qw(fatalsToBrowser); has no effect on their servers.

I would really like to know how it's possible for an individual server
to break CGI::Carp.  The module, as I understand it, sets up a
$SIG{__DIE__} routine to capture Perl syntax & runtime errors and
prints a standard HTTP Header followed by the error message to STDOUT.

Paul Lalli

Paul Lalli wrote:
> Eric Martin wrote:
> 
>
> I would really like to know how it's possible for an individual server
> to break CGI::Carp.  The module, as I understand it, sets up a
> $SIG{__DIE__} routine to capture Perl syntax & runtime errors and
> prints a standard HTTP Header followed by the error message to STDOUT.
>
> Paul Lalli
>

Just to be sure, I went out an signed up for a hosting account (Linux
Deluxe)...and here are the results (drum roll):

GoDaddy script #1 : good.pl
#!/usr/bin/perl
use strict;
use warnings;
use CGI qw(:standard);
print header;
print 'Works!';
exit;

Results:
Works!

GoDaddy script #2: bad.pl
#!/usr/bin/perl
use strict;
use warnings;
use CGI::Carp qw(fatalsToBrowser);
require 'non-existent-file.pm';
exit;

Results:
Internal Server Error

Error Log:
Can't locate non-existent_file.pm in @INC (@INC contains:
/usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 .) at
/home/content/x/x/x/x/html/cgi/bad.pl line 5.
[Fri Jul 14 16:25:18 2006] [error] [client 63.205.213.31] Premature end
of script headers: /var/chroot/home/content/x/x/x/x/html/cgi/bad.pl


Local script #2 : bad.pl (WindowsXP/Apache2)
#!perl
use strict;
use warnings;
use CGI::Carp qw(fatalsToBrowser);
require 'non-existent-file.pm';
exit;

Results:
Software error:
Can't locate non-existent-file.pm in @INC (@INC contains: C:/Perl/lib
C:/Perl/site/lib .) at C:/Program Files/Apache
Group/Apache2/cgi-bin/bad.pl line 5.

I too would like to know why this happens. I will contact their support
and see what they have to say...

Also, a correction to a previous statement I made, Error Logs are
available and can be enabled for a 24-hour period.

Thanks,
Eric

Eric Martin wrote:
> Paul Lalli wrote: 
>
> Just to be sure, I went out an signed up for a hosting account (Linux
> Deluxe)...and here are the results (drum roll):
>

[snip]

>
> GoDaddy script #2: bad.pl
> #!/usr/bin/perl
> use strict;
> use warnings;
> use CGI::Carp qw(fatalsToBrowser);
> require 'non-existent-file.pm';
> exit;
>
> Results:
> Internal Server Error
>
> Error Log:
> Can't locate non-existent_file.pm in @INC (@INC contains:
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0
> /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl
> /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 .) at
> /home/content/x/x/x/x/html/cgi/bad.pl line 5.
> [Fri Jul 14 16:25:18 2006] [error] [client 63.205.213.31] Premature end
> of script headers: /var/chroot/home/content/x/x/x/x/html/cgi/bad.pl
>
>

[snip]

>
> I too would like to know why this happens. I will contact their support
>  and see what they have to say...
>

Well, here is their very helpful response:

quote:

Thank you for contacting Customer Support. Unfortunately, we cannot
support custom coding/scripting in anyway. I apologize for the
inconvenience.

Please let us know if we can help you in any other way.


*sigh*

[snip]

I sent them back a note ... we'll see if I get a response.

-Eric

Eric:

I tried good.pl, and <a href="http://www.adampolt.com/cgi/test.cgi">as
you can see</a> it fails miserably for me.

I used the exact code you posted:

#!/usr/bin/perl
use strict;
use warnings;
use CGI qw(:standard);
print header;
print 'Works!';
exit;

This is really frustrating.

Adam Polt wrote:
> Eric:
>
> I tried good.pl, and <a href="http://www.adampolt.com/cgi/test.cgi">as
> you can see</a> it fails miserably for me.
>
> I used the exact code you posted:
>
> #!/usr/bin/perl
> use strict;
> use warnings;
> use CGI qw(:standard);
> print header;
> print 'Works!';
> exit;
>
> This is really frustrating.
>

What hosting plan did you sign up for? I am on the Linux Deluxe plan.

Here is what I would do:
1) Make sure you ftp'd the file in ASCII mode
2) Make sure you changed the permissions on the script to 755
3) Enable the error logs in the account control panel. Then run your
script. Then launch the CGI Admin to view the actual error in the log.

HTH!

-Eric

I'm way too simple minded for you guys. I name my perl scripts with a .pl
extension. I usually set the permissions to 755. I also make sure the
filename is exactly the same case as what I try to run. Capitals are not the
same as lowercase.

So as an experiment I took the code shown below and put it on my godaddy
site as good.cgi and changed permissions to 744 and it runs just fine.




"Eric Martin" <emartin24@gmail.com> wrote in message
 news:W6udnYyti4JMIyDZnZ2dnUVZ_r2dnZ2d@st
arstream.net...
> Adam Polt wrote: 
>
> What hosting plan did you sign up for? I am on the Linux Deluxe plan.
>
> Here is what I would do:
> 1) Make sure you ftp'd the file in ASCII mode
> 2) Make sure you changed the permissions on the script to 755
> 3) Enable the error logs in the account control panel. Then run your
> script. Then launch the CGI Admin to view the actual error in the log.
>
> HTH!
>
> -Eric