CODEWITHSUNDEEP
perlcgi
User12321313
User12321313

Reputation: 141

Error 500 when with perl cgi - but not any of the common pitfalls

I have a very tricky to diagnose perl problem, that has been seriously hampering my ability to maintain a perl/cgi website. It usually occurs when editing a script - after a change I get error 500, and then after I revert it it wont work again unless I delete the file and start from scratch, however I currently have a state which it can be reproduced by the following simple two scripts which show just how crazy this bug is:

file1.pl

#! /usr/bin/perl
use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
print "content-type: text/html\n\nIt works";

file2.pl

#! /usr/bin/perl
use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
print "content-type: text/html\n\nIt works";

(Ie... they're identical)

server.com/cgi-bin/file1.pl works

server.com/cgi-bin/file2.pl results in error 500

Both files have the same size and md5 hash. Both have the same permissions (755) and the same owner and group. Both are in the correct folder (hosting supplied cgi-bin). Both were uploaded in text mode. Both work with local perl interpreters.

If i rename file1 -> file3, file2 -> file1, and file3->file2, (ie swapping both files), now file2.pl works and file1.pl doesn't. So my guess is some state is attached to the files themselves.

If i edit the files in filezilla and re-upload (eg add some whitespace after a semicolon), same behaviour occurs with the re-uploaded files.

My error 500 page is set to auto-retry using a meta refresh (in case of out memory errors, etc), and it doesn't go away after countless refreshes. It doesn't seem to matter which ones is accessed first.

I do not have access to the http error_log on this hosting so do not know the reason for the failure. The error also occurs without the "use error messages to browser" diagnostic line.

Can anyone give me a hint as to what this could be and help me fix it?

Upvotes: 1

Views: 406

Answers (4)

Charlie Chan
Charlie Chan

Reputation: 1

I have had the same problem, got help from user BOC as below: "You may have problem with encoding of characters. Some editors replace some characters by very close characters when you save files (for example " by “). Try changing editor (notepad++ works well on windows). – BOC" I downloaded and used Notepad++ instead of Notepad and Winword; It works now for me.

Upvotes: 0

afenster
afenster

Reputation: 3608

What you describe can be either caused by some problem on your hosting provider side (some bad caching, or transparent proxies, or any other magic), or—and that is what I think it is—still caused by wrong file permissions or line breaks, even if your file manager reports that everything is good.

If I'm reading your description correctly you basically

  • can put a script and it will work, but
  • cannot edit it as it will stop working after that.

As you don't have shell access, just put the following small script to the same directory and run it (hope it will run as you are not going to edit it):

#!/usr/bin/perl
use strict;
use warnings;

print "Content-Type: text/plain\n\n";

opendir( my $dirh, "." );
my @files = grep { -f $_; } readdir $dirh;
closedir $dirh;

foreach my $file (@files) {
    my @stat = stat $file;
    my ($dev,  $ino,   $mode,  $nlink, $uid,     $gid, $rdev,
        $size, $atime, $mtime, $ctime, $blksize, $blocks
    ) = stat($file);
    my $octmode = sprintf "%04o", $mode & 07777;
    print "$file\tmode=$octmode\tuid=$uid\tgid=$gid\tsize=$size\t";
    if ( -r $file ) {
        open( my $fh, $file );
        my $firstline = <$fh>;
        print $firstline =~ /\r\n/ ? "crlf\n" : "lf\n";
        close $fh;
    } else {
        print "can't read\n";
    }
}

It will show the real permissions, linebreaks, and size of the files—those taken from the server's filesystem, not which your FTP client shows.

Maybe it's worth adding MD5 or SHA1 hash calculation to this script but not sure if you have Digest::MD5 or Digest::SHA1 available.

If you see the same output for test1.pl and test2.pl, just go ahead and contact your hosting provider's support.

Upvotes: 2

Miller
Miller

Reputation: 35198

Not being able to inspect the errorlog is a big headache.

Nevertheless, I suspect that the cause is still most likely line endings. I would upload a script to examine all of your files like the following:

#!/usr/bin/env perl
use strict;
use warnings;
use autodie;

use CGI qw(header);
use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
use File::stat;

print header('text/plain');

my $fmt = "%-15s %4s %4s %4s %7s %4s %4s\n";
printf $fmt, qw(File mode uid gid size lf crlf);
printf $fmt, map { '-' x $_ } $fmt =~ /(\d+)/g;

opendir my $dh, '.';
while ( my $file = readdir $dh ) {
    next unless -f $file;

    my $stat = stat $file;

    my %chars;
    my $data = do { local ( @ARGV, $/ ) = $file; <> };
    $chars{$1}++ while $data =~ /(\R)/g;

    printf $fmt, $file, sprintf( "%04o", $stat->mode & 07777 ), $stat->uid,
        $stat->gid, $stat->size, map { $_ // 0 } @chars{ "\n", "\r\n" };
}

Outputs:

Content-Type: text/plain; charset=ISO-8859-1

File            mode  uid  gid    size   lf crlf
--------------- ---- ---- ---- ------- ---- ----
env.cgi         0775    0    0     266   25    0
le.pl           0775  501    0     696   28    0
lineendings.pl  0755  501    0     516   30    0
mywiki.pl       0755  501    0  226947    0 6666
test.cgi        0755    0    0    2071   65    0
wiki.pl         0755    0    0  219231 6494    0

For additional testing, I would recommend executing each of the scripts using system and inspecting the error conditions if there are any.

Upvotes: 0

reinierpost
reinierpost

Reputation: 8591

My guess: the files don't use the same newline convention. You can check this (in a Unix shell) using the file command.

Upvotes: 0

Related Questions