Re: Re: LWP::UserAgent connection problem as CGI

Thanks for the lengthy response. I tried your script and it failed on the problem server, and succeeded on the working server. Given that, you are saying that if the issue is likely permissions. As stated in my original post, my script works at command line whether as root, or as the user that apache runs as. For the record, I am indeed testing on the same machine as the CGI is running. Same script, actually, with a use lib statement added to lead to our modules (a line usually provided by mod_perl).

I also tried running your test script with the shebang line pointing to any perl install I could find, as well as without a shebang line, using all of the different perl installs before the script name. Is there another way that permissions could be affecting this that I am not seeing, or can you suggest further tests to help me narrow this down? I also added the following line to your script:

print "\nVERSION: ".`perl -v`."\n";

The version was always displayed as 5.8.0, regardless of what I tried to make it use (via shebang or command line). The perl installs appear to be different (not just symbolic links to one). The @INC array did change with each different shebang line:

#!/usr/bin/perl
#!/usr/local/bin/perl
#!/usr/local/bin/perl5.8.0
[download]

produce:

/usr/local/lib/perl5/5.8.0/i386-freebsd
/usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl
[download]

#!/usr/bin/perl5
#!/usr/bin/perl5.00503
[download]

produce:

/usr/local/lib/perl5/site_perl/5.005/i386-freebsd
/usr/local/lib/perl5/site_perl/5.005
/usr/libdata/perl/5.00503/mach
/usr/libdata/perl/5.00503
[download]

Update: Fixed shebang typos (second group).

Not sure if any of that helps at all...

bassplayer

Comment on Re: Re: LWP::UserAgent connection problem as CGI Select or Download Code

Replies are listed 'Best First'.

Re: Re: Re: LWP::UserAgent connection problem as CGI
by tachyon (Chancellor) on Mar 03, 2004 at 20:36 UTC

When you say failed I presume you mean it printed choked. Here is the same script as a command line utility. Run it on the server that choked. As root, and as nobody/apache.

#!/usr/bin/perl
my $host = gethostbyname($ARGV[0]);
print $host ? "Got host $host\n" : "Choked!";
[download]

It fails because gethostbyname() is failing. Some systems do have a crap gethostbyname(). In fact freebsd (which I see is what you are using) is one such OS. Do a google for 'gethostbyname freebsd perl issue' or some such. From memory the gethostbyname function is not thread safe up until the most recent of the freebsd releases.

So.....

Freebsd has known issues with gethostbyname. I use Linux so don't know the details but there may be a patch for the core function.
You have now effectively isolated the bug to gethostbyname() failing under some circumstances and have a test case.
You are using 5.8.0 which was by all reports less than optimal. I would strongly consider recomiling perl using 5.8.3. I seem to remember there is the option to not use the systems native gethostbyname() - something like 'system has broken gethostbyname()' so let perl know.
Getting 5.8.3, compiling, installing it into the default location (/usr/local/lib/perl5/5.8.3) will not overwrite anything and will probably be the quickest fix if it works. It will take about 15 minutes or so to do.

You may need to install libwwwperl (if you do not include the old 5.8.0 lib and site/lib into @INC during the configure. Anyway if you do it is just /usr/local/bin/perl5.8.3 Makefile.PL && make && make test && make install. This forces linking to 5.8.3 and installation into the 5.8.3 tree. Once it is in all you need to do to the test case is put #!/usr/local/bin/perl5.8.3 to run the test case against the new perl. If it works you have a cure. I would then just remove/rename the /usr/bin/perl (probably a symlink) and link it to the new 5.8.3 binary. You can always undo the link if random stuff happens (like none of the 5.8.0 modules can get found as the lib paths were not compiled into your new perl)

cheers

tachyon

[reply]
[d/l]
[select]


The stupid question is the question not asked
	PerlMonks