I got a connection test script that is run on my client system and is calling a Perl DBI Proxy server via
my $dbh = DBI->connect("dbi:Proxy:$dbiproxy;dsn=$dsn", "$user","$pass",{ PrintError => 1}) || ($errmsg = "ERROR on connect");
When running the script it will fail stating
connect('hostname=***;port=2001;dsn=dbi:Oracle:***','***',...) failed: Cannot log in to DBI::ProxyServer: Unexpected EOF from server at /usr/local/share/perl/5.10.1/RPC/PlClient.pm line 79.
The log on the DBI Proxy server reads
Wed Dec 15 14:47:47 2015 err, Child died: Storable binary image v2.7 more recent than I am (v2.6) at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/thaw.al) line 363, at /usr/lib/perl5/site_perl/5.8.0/RPC/PlServer/Comm.pm line 179
So I checked the Perl and Storable module version numbers of the two systems and the DBI proxy server seems to be rather outdated:
source: perl 5.10.1, storable 2.20, storable 2.7 (binary), Debian 6.0
target: perl 5.8.0 , storable 2.13, storable 2.6 (binary), RHEL 3
The problem is that I can not update the module/perl version of the target system, so I thought I could simply lower the utilized client version by modifying the /usr/local/share/perl/5.10.1/RPC/PlServer/Comm.pm file and change the line
require Storable;
to
use Storable 2.13;
but this will result in the same error as above. I also tried to use Storable 2.13 directly in my Perl test-script, but that does not change anything, either.
When googling this I could not find any solution, only confirmation that this version discrepancy can be a problem. Increasing the DBI_TRACE level on the client side also did not reveal anything new. Frankly I don't know what to try next and any help would be greatly appreciated.
Related
I am getting issues when trying to install Perl modules on Ubuntu running on Windows 10.
I am not sure the best way to post the output, I am guessing maybe as "code"
$ cpan HTTP::Tiny
Loading internal logger. Log::Log4perl recommended for better logging
Reading '/home/user/.cpan/Metadata'
Database was generated on Sun, 06 Nov 2022 23:29:01 GMT
Running install for module 'HTTP::Tiny'
Fetching with HTTP::Tiny:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/HTTP-Tiny-0.082.tar.gz
Fetching with HTTP::Tiny:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/CHECKSUMS
Checksum for /home/user/.cpan/sources/authors/id/D/DA/DAGOLDEN/HTTP-Tiny-0.082.tar.gz ok
sh: 1: /usr/bin/gzip: Exec format error
/usr/bin/tar: This does not look like a tar archive
/usr/bin/tar: Exiting with failure status due to previous errors
Uncompressed /home/user/.cpan/sources/authors/id/D/DA/DAGOLDEN/HTTP-Tiny-0.082.tar.gz successfully
Using Tar:/usr/bin/tar xf "HTTP-Tiny-0.082.tar":
Untarred HTTP-Tiny-0.082.tar successfully
'YAML' not installed, will not store persistent state
Package contains both files[HTTP-Tiny-0.082.tar] and directories[HTTP-Tiny-0.082]; not recognized as a perl package, giving up
Configuring D/DA/DAGOLDEN/HTTP-Tiny-0.082.tar.gz with Makefile.PL
Running make for D/DA/DAGOLDEN/HTTP-Tiny-0.082.tar.gz
make: *** No targets specified and no makefile found. Stop.
DAGOLDEN/HTTP-Tiny-0.082.tar.gz
/usr/bin/make -- NOT OK
I am really suck on how to fix this, I have been scratching my head for a few days now and any assistance would be really appreciated.
Based on the log it seems to be an issue specifically with Ubuntu 22.04 on WSL1:
sh: 1: gzip: Exec format error
see: gzip from Ubuntu Jammy doesn't execute #8219
You could install an earlier version of gzip via. apt that works well – however the best route would be to update to WSL 2, as it has many benefits and it won't have this issue.
See the comparison page including some rare cases where you might want to stay on WSL 1.
I have a script that uses Net::SSH:Perl module. It is able to ssh to RHEL6.9 hosts but not RHEL7.4 hosts. I get the following error:
Protocol error: expected packet type 91, got 80 at /Net/SSH/Perl/Packet.pm line 221
How do I remedy this?
A simple search for the error message gives this post from 2016 and this bug report from 2016 which both indicate that the issue was fixed in version 2.01 of the module, released in 10/2016. Thus, you are probably using an older version and need to upgrade.
I have interest to programmatically take a screenshot of a webpage using perl. I have come across this solution:
use WWW::Mechanize::Firefox;
use Path::Class qw/file/;
my $mech = WWW::Mechanize::Firefox->new(
bufsize => 10_000_000, # PNGs might become huge
);
$mech->get('http://www.stackoverflow.com/');
my $fh = file( 'test.png' )->open( '> :raw' );
print $fh $mech->content_as_png();
but when I try to run this code I get:
Failed to connect to , problem connecting to "localhost", port 4242:
Connection refused at /usr/local/share/perl/5.20.2/MozRepl/Client.pm
line 144
It was suggested that this failure is due to a closed port (Debian Jessie, Apache2, Perl 5.20), or MozRepl not installed or not configured correctly.
The Debian server is a command line only, and there is no graphic interface otherwise. When I run cpan WWW::Mechanize::Firefox I get at the end:
CPAN: Storable loaded ok (v2.49_01)
Reading '/root/.cpan/Metadata'
Database was generated on Fri, 22 Jul 2016 17:53:33 GMT
CPAN: Module::CoreList loaded ok (v5.20150214)
WWW::Mechanize::Firefox is up to date (0.79).
And when I run cpan MozRepl, I get at the end:
CPAN: Storable loaded ok (v2.49_01)
Reading '/root/.cpan/Metadata'
Database was generated on Fri, 22 Jul 2016 17:53:33 GMT
CPAN: Module::CoreList loaded ok (v5.20150214)
MozRepl is up to date (0.06).
So as the title asks, can the above code work if there is no graphical interface? If yes, what can I do to debug and solve this issue?
2 solutions:
Xvfb to create a headless X server, and have the firefox instance running on it
Use Phantom, and this seems to be a good tutorial: http://blogs.perl.org/users/robhammond/2013/02/web-scraping-with-perl-phantomjs.html
Using MongoDB 2.4.5 with version 0.702 of the Perl MongoDB driver, I frequently run into exceptions like these:
recv timed out (30000 ms) at ...MongoDB/Cursor.pm line 161.
couldn't get response to throw out at ...MongoDB/Cursor.pm line 161.
missed the response we wanted, please try again at ...MongoDB/Cursor.pm line 161
invalid header received at ...MongoDB/Cursor.pm line 161.
can't get db response, not connected at ...MongoDB/Cursor.pm line 161.
The exceptions are intermittent, and often vanish on the next request (this is a web app). Occasionally, the exceptions will persist over several consecutive requests.
This is a tiny database running the default configuration (no sharding or anything fancy). I've tried using some of the tools listed here and here, but I'm unclear on how to apply them to this situation.
This is all running on Debian 7.1 64-bit. The web server is Mojolicious' hypnotoad 4.07 on perl 5.16.3 running behind apache2.
Can you kindly suggest some tools & strategies for diagnosing the problem? Thanks for your time.
Each time LWP::UserAgent or LWP::Simple is used with mod_perl (PerlRun), Ubuntu 10.04.4 and Apache 2.2.14 I get about 50 or so error messages in the Apache error log:
Constant subroutine ModPerl::ROOT::ModPerl::PerlRun::home_user_public_html_index_2ecgi::RC_NOT_IMPLEMENTED redefined at /usr/lib/perl5/ModPerl/Util.pm line 69.
I have attempted defining the functions I will be using as:
use LWP::UserAgent qw(agent request);
However I am still getting these error messages. They are filling up the Apache error log very fast.
I think no warnings 'redefine'; will work.
use strict;
use warnings;
no warnings 'redefine';
Is how I usually do it.