I believe I fixed this in the commit on 2/6. There are a bunch of CPAN options which get configured in a hash in the configure_cpan subroutine. These options need to be configured so that CPAN module installs are non-interactive. I included all the options I could find in this hash to prevent CPAN from asking any questions. One of the options is "tar_verbosity". It had previously been set to 0. It seems as though CPAN takes this parameter and adds "-0" to the tar arguments. I changed it to a blank string and it seems to have solved the problem.
-Andy On Fri, Feb 17, 2012 at 9:06 AM, Aaron Peeler <aaron_pee...@ncsu.edu> wrote: > Hi Mike, > > When you ran the latest install_perl_libs.pl. > > Did you see any errors in the CPAN section - should be toward the end > of the output. > That had: > cpan tar: Options `-[0-7][lmh]' not supported by *this* tar > > I'm seeing an error related to config option for cpan that the > verbosity level is set wrong on different linux OS versions. It's not > consistent, so just checking to see if you had seen this. > > Thanks, > Aaron > > > On Mon, Feb 6, 2012 at 3:53 PM, Mike Haudenschild <m...@longsight.com> wrote: >> Hi Andy, >> >> I pulled down the updated install_perl_libs.pl and used alongside the 2.2.1 >> management node release. I did notice that libwww was installed to satisfy >> dependencies for perl-xml-simple. I didn't do any other tweaking -- just >> ran the script and otherwise followed the "normal" management node install >> procedure. >> >> A block allocation didn't work, however: >> >> |3394|blockrequest| ---- CRITICAL ---- >> |3394|blockrequest| 2012-02-06 >> 15:51:44|3394|blockrequest|vcld:die_handler(636)|Can't locate object method >> "type" via package "RPC::XML::Client::send_request: HTTP server error: you >> need" (perhaps you forgot to load "RPC::XML::Client::send_request: HTTP >> server error: you need"?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line >> 9121. >> |3394|blockrequest| ( 0) vcld, die_handler (line: 636) >> |3394|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) >> |3394|blockrequest| (-2) blockrequest.pm, process_block_time (line: 373) >> |3394|blockrequest| (-3) blockrequest.pm, process (line: 193) >> |3394|blockrequest| (-4) vcld, make_new_child (line: 568) >> |3394|blockrequest| (-5) vcld, main (line: 448) >> >> >> On Mon, Feb 6, 2012 at 12:23, Andy Kurth <andy_ku...@ncsu.edu> wrote: >> >>> I updated install_perl_libs.pl in the repository: >>> >>> https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl >>> >>> You should now be able to run it without having to perform any >>> additional steps. Please give it a try. >>> >>> Thanks, >>> Andy >>> >>> On Wed, Feb 1, 2012 at 1:53 PM, Mike Haudenschild <m...@longsight.com> >>> wrote: >>> > All, >>> > >>> > I've managed to get around the CRITICAL error I was seeing in the vcld >>> log >>> > during block allocations. perl-libwww-perl wasn't installed. *sigh* >>> > Installing that prior to running install_perl_libs.pl solved the >>> problem >>> > (should that be added to the install_perl_libs script?). I noticed that >>> > there are two listings of PERL-related software required for the >>> management >>> > node: >>> > >>> > >>> https://cwiki.apache.org/confluence/display/VCL/VCL+2.2.1+Management+Node+Installation >>> > >>> > and >>> > >>> > https://cwiki.apache.org/confluence/display/VCL/Apache+VCL >>> > >>> > We might want to consolidate those. I was running from the install docs >>> > and didn't even think to check that perl-libwww-perl was installed. >>> > >>> > Prior to this, I'd developed a manual workaround, installing RPC-XML 0.71 >>> > (which is NOT the most recent version) using the make method from the >>> CPAN >>> > archive. >>> > >>> > Note that I'm on CentOS 5.7, clean install and fully updated prior to >>> > install VCL management node. There is no package perl-XML-RPC (called >>> from >>> > the script) available from the repos (with EPEL enabled), >>> > and perl-libwww-perl wasn't installed by default. >>> > >>> > Here's the process I used... >>> > >>> > 1. Used the 2.2.1 release install_perl_libs.pl script >>> > 2. Commented out the line that tells install_perl_libs.pl to retrieve >>> > RPC::XML from CPAN (line 285) >>> > 3. Ran install_perl_libs.pl >>> > 4. Installed RPC-XML 0.71 from CPAN >>> > 5. Completed VCL management node install steps from the documentation >>> > >>> > I went with the lowest-versions of the various dependencies needed by >>> > RPC-XML 0.71, which is obviously not a best-practice... I'd appreciate >>> any >>> > feedback from the list on whether that may have unintended >>> consequences... >>> > >>> > Here's the dependency tree with links: >>> > >>> > - RPC-XML 0.71 (http://search.cpan.org/~rjray/RPC-XML-0.71/) >>> > - libwww-perl (LWP) 5.801 ( >>> > https://metacpan.org/release/GAAS/libwww-perl-5.801) >>> > - URI 1.10 (https://metacpan.org/release/GAAS/URI-1.10) ... note >>> > that some tests FAILED >>> > - HTML-Parser 3.33 ( >>> > https://metacpan.org/release/GAAS/HTML-Parser-3.33) >>> > - HTML-Tagest 3.02 ( >>> > https://metacpan.org/release/SBURKE/HTML-Tagset-3.02/) >>> > - XML-Parser 2.31 ( >>> > https://metacpan.org/release/COOPERCL/XML-Parser-2.31) >>> > >>> > Having the most recent perl-libwww-perl from CPAN yielded an install that >>> > didn't include LWP::Protocol::https (and the script is trying to make an >>> > HTTPS connection). Installing LWP-Protocol-https doesn't solve the >>> problem >>> > because of stricter SSL certification requirements and hostname >>> > verification ( >>> > >>> http://search.cpan.org/~gaas/LWP-Protocol-https-6.02/lib/LWP/Protocol/https.pm >>> > ). >>> > >>> > Many thanks, >>> > Mike >>> > >>> > >>> > On Wed, Feb 1, 2012 at 11:44, Andy Kurth <andy_ku...@ncsu.edu> wrote: >>> > >>> >> You shouldn't have to install anything manually. It looks like there >>> >> are some problems with the current install_perl_libs.pl script. There >>> >> is a CPAN "notest" option which I added to make the script run a lot >>> >> faster. Apparently this option isn't always available. Try editing >>> >> install_perl_libs.pl and then run it again. Swap the comment from the >>> >> "install" line to the "notest" line, change: >>> >> >>> >> eval { CPAN::Shell->notest("install", $perl_module) }; >>> >> #eval { CPAN::Shell->install($perl_module) }; >>> >> >>> >> -to- >>> >> >>> >> #eval { CPAN::Shell->notest("install", $perl_module) }; >>> >> eval { CPAN::Shell->install($perl_module) }; >>> >> >>> >> >>> >> Also, was epel successfully installed? Run 'yum repolist'. Do you >>> >> see epel listed? If not, check the install_perl_libs.pl output for >>> >> errors when it tries to install it. >>> >> >>> >> -Andy >>> >> >>> >> >>> >> On Tue, Jan 31, 2012 at 6:07 PM, Mike Haudenschild <m...@longsight.com> >>> >> wrote: >>> >> > Here's the output: >>> >> > >>> >> > @@@@@ >>> >> > XML::LibXML not found >>> >> > >>> >> > You may ignore the warnings about XML::LibXML not being >>> present, >>> >> if >>> >> > you plan only to use the XML::Parser-based parsing engine. The >>> use >>> >> > of XML::LibXML is completely optional. >>> >> > @@@@@ >>> >> > >>> >> > WARNING: MIN_PERL_VERSION is not a known parameter. >>> >> > WARNING: META_MERGE is not a known parameter. >>> >> > WARNING: LICENSE is not a known parameter. >>> >> > Warning: prerequisite LWP 5.834 not found. We have 5.805. >>> >> > Warning: prerequisite Test::More 0.94 not found. We have 0.62. >>> >> > 'LICENSE' is not a known MakeMaker parameter name. >>> >> > 'META_MERGE' is not a known MakeMaker parameter name. >>> >> > 'MIN_PERL_VERSION' is not a known MakeMaker parameter name. >>> >> > Writing Makefile for RPC::XML >>> >> > >>> >> > >>> >> > >>> >> > On Tue, Jan 31, 2012 at 17:52, Mike Haudenschild <m...@longsight.com> >>> >> wrote: >>> >> > >>> >> >> Hi Aaron, >>> >> >> >>> >> >> You're right, RPC-XML wasn't installed, although perl-libwww-perl is >>> >> >> installed and updated. >>> >> >> >>> >> >> Should I install RPC-XML AFTER I run install_perl_libs.pl? (I get >>> >> errors >>> >> >> when I run Makefile about various missing prerequisites on a clean >>> >> CentOS >>> >> >> install.) >>> >> >> >>> >> >> Thanks, >>> >> >> Mike >>> >> >> >>> >> >> On Tue, Jan 31, 2012 at 16:49, Aaron Coburn <acob...@amherst.edu> >>> >> wrote: >>> >> >> >>> >> >>> Oh. It looks like RPC-XML is not installed. >>> >> >>> >>> >> >>> You can verify that by using this command: >>> >> >>> >>> >> >>> perl -MRPC::XML -e "print 'have a nice day'" >>> >> >>> >>> >> >>> If you get errors, the module isn't installed. If the script seems >>> >> >>> friendly, then the module is installed. >>> >> >>> >>> >> >>> If the module is not installed, download it from here: >>> >> >>> http://search.cpan.org/dist/RPC-XML/ >>> >> >>> >>> >> >>> unpack it and install it like so: >>> >> >>> >>> >> >>> perl Makefile.PL >>> >> >>> make && make test >>> >> >>> sudo make install >>> >> >>> >>> >> >>> Then try the command again that I listed above. >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> On Jan 31, 2012, at 4:42 PM, Mike Haudenschild wrote: >>> >> >>> >>> >> >>> > Hi Aaron, >>> >> >>> > >>> >> >>> > I get the following errors running install_perl_libs from trunk, >>> on >>> >> >>> CentOS >>> >> >>> > 5.7 fully updated: >>> >> >>> > >>> >> >>> > *No package perl-CPAN available.* >>> >> >>> > *WARNING: unexpected output returned while installing Linux >>> package: >>> >> >>> > 'perl-CPAN'* >>> >> >>> > *this has happened since my first install, but doesn't seem to be >>> a >>> >> >>> problem >>> >> >>> > since cpan is already installed in CentOS base >>> >> >>> > >>> >> >>> > *No package perl-RPC-XML available.* >>> >> >>> > *WARNING: unexpected output returned while installing Linux >>> package: >>> >> >>> > 'perl-RPC-XML'* >>> >> >>> > *this has also happened since my first install, but I've never >>> been >>> >> >>> able to >>> >> >>> > resolve this. I thought perhaps the CPAN commands issued at the >>> end >>> >> of >>> >> >>> the >>> >> >>> > install script installed RPC::XML from CPAN...? >>> >> >>> > >>> >> >>> > All of the PERL module installs throw: >>> >> >>> > *Unknown command 'notest'. Type ? for help.* >>> >> >>> > >>> >> >>> > Two PERL modules fail to install: >>> >> >>> > >>> >> >>> > *Attempting to install Perl module using CPAN: >>> 'Object::InsideOut'* >>> >> >>> > *Unknown command 'notest'. Type ? for help.* >>> >> >>> > *checking if Object::InsideOut Perl module is installed...* >>> >> >>> > *Perl module Object::InsideOut appears to be installed but the >>> >> version >>> >> >>> > could not be determined* >>> >> >>> > *command: perl -e "eval \"use Object::InsideOut\"; print >>> >> >>> > \$Object::InsideOut::VERSION" 2>&1* >>> >> >>> > *output:* >>> >> >>> > *ERROR: failed to install Perl module: 'Object::InsideOut'* >>> >> >>> > >>> >> >>> > >>> >> >>> > *Attempting to install Perl module using CPAN: 'RPC::XML'* >>> >> >>> > *Unknown command 'notest'. Type ? for help.* >>> >> >>> > *checking if RPC::XML Perl module is installed...* >>> >> >>> > *Perl module RPC::XML appears to be installed but the version >>> could >>> >> not >>> >> >>> be >>> >> >>> > determined* >>> >> >>> > *command: perl -e "eval \"use RPC::XML\"; print >>> \$RPC::XML::VERSION" >>> >> >>> 2>&1* >>> >> >>> > *output:* >>> >> >>> > *ERROR: failed to install Perl module: 'RPC::XML'* >>> >> >>> > >>> >> >>> > Thanks!! >>> >> >>> > Mike >>> >> >>> > >>> >> >>> > -- >>> >> >>> > *Mike Haudenschild* >>> >> >>> > Education Systems Manager >>> >> >>> > Longsight Group >>> >> >>> > (740) 599-5005 x809 >>> >> >>> > m...@longsight.com >>> >> >>> > www.longsight.com >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> > On Tue, Jan 31, 2012 at 14:43, Aaron Peeler < >>> aaron_pee...@ncsu.edu> >>> >> >>> wrote: >>> >> >>> > >>> >> >>> >> Hi Mike, >>> >> >>> >> >>> >> >>> >> Apologies for not responding on this. >>> >> >>> >> >>> >> >>> >> Are you still seeing this issue with your block allocations? >>> >> >>> >> >>> >> >>> >> If so you could try to use the latest install_perl_libs.plscript >>> >> >>> >> >>> >> >>> >> >>> >> >>> >>> >> >>> https://svn.apache.org/repos/asf/incubator/vcl/trunk/managementnode/bin/install_perl_libs.pl >>> >> >>> >> >>> >> >>> >> Aaron >>> >> >>> >> >>> >> >>> >> On Wed, Jan 25, 2012 at 6:40 PM, Mike Haudenschild < >>> >> m...@longsight.com >>> >> >>> > >>> >> >>> >> wrote: >>> >> >>> >>> Dev team, >>> >> >>> >>> >>> >> >>> >>> I would very much appreciate guidance on whether I should try >>> >> defining >>> >> >>> >> (or >>> >> >>> >>> bypassing) the SSL cert variables in the PERL scripts, or if I >>> >> >>> should/can >>> >> >>> >>> downgrade the applicable PERL modules to older known-working >>> >> versions >>> >> >>> to >>> >> >>> >>> workaround this issue altogether. >>> >> >>> >>> >>> >> >>> >>> The log was telling me that LWP::Protocol::https was required, >>> and >>> >> >>> it's >>> >> >>> >> not >>> >> >>> >>> installed by the install_perl_libs script (because >>> >> >>> LWP::Protocol::https >>> >> >>> >> was >>> >> >>> >>> recently split out from libwww-perl?). Once installed, >>> however, I >>> >> get >>> >> >>> >>> static as shown in the logs below. >>> >> >>> >>> >>> >> >>> >>> I'm dead in the water with block allocations. Thanks very much >>> for >>> >> >>> any >>> >> >>> >>> help. >>> >> >>> >>> >>> >> >>> >>> Regards, >>> >> >>> >>> Mike >>> >> >>> >>> >>> >> >>> >>> >>> >> >>> >>> On Tue, Jan 24, 2012 at 21:00, Mike Haudenschild < >>> >> m...@longsight.com> >>> >> >>> >> wrote: >>> >> >>> >>> >>> >> >>> >>>> Good evening, >>> >> >>> >>>> >>> >> >>> >>>> I apologize for the numerous emails, but as I continue working >>> >> >>> through >>> >> >>> >>>> this something new popped up: >>> >> >>> >>>> >>> >> >>> >>>> I managed to get LWP::Protocol::https to install by first >>> updating >>> >> >>> >>>> Net::SSLLeay with CPAN. >>> >> >>> >>>> >>> >> >>> >>>> However, when making a block allocation I now get this in the >>> log: >>> >> >>> >>>> >>> >> >>> >>>> |4978|blockrequest| ---- CRITICAL ---- >>> >> >>> >>>> |4978|blockrequest| 2012-01-24 20 >>> >> >>> >> :53:45|4978|blockrequest|vcld:die_handler(636)|Can't >>> >> >>> >>>> locate object method "type" via package >>> >> >>> "RPC::XML::Client::send_request: >>> >> >>> >>>> HTTP server error:* Can't connect to vclserver:443< >>> >> >>> >> http://urichmond.longsight.com:443>(certificate verify failed) >>> >> >>> >>>> *" (perhaps you forgot to load "RPC::XML::Client::send_request: >>> >> HTTP >>> >> >>> >>>> server error: Can't connect to server.domain.com:443(certificate >>> >> >>> >> verify >>> >> >>> >>>> failed)"?) at /usr/local/vcl/bin/../lib/VCL/utils.pm line >>> 9121. >>> >> >>> >>>> |4978|blockrequest| ( 0) vcld, die_handler (line: 636) >>> >> >>> >>>> |4978|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) >>> >> >>> >>>> |4978|blockrequest| (-2) blockrequest.pm, process_block_time >>> >> (line: >>> >> >>> >> 373) >>> >> >>> >>>> |4978|blockrequest| (-3) blockrequest.pm, process (line: 193) >>> >> >>> >>>> |4978|blockrequest| (-4) vcld, make_new_child (line: 568) >>> >> >>> >>>> |4978|blockrequest| (-5) vcld, main (line: 448) >>> >> >>> >>>> >>> >> >>> >>>> 2012-01-24 20 >>> >> >>> >> :53:45|4978|blockrequest|State.pm:DESTROY(829)|VCL::blockrequest >>> >> >>> >>>> destructor called, address: f7be070 >>> >> >>> >>>> 2012-01-24 20 >>> >> :53:45|4978|blockrequest|State.pm:DESTROY(848)|number >>> >> >>> of >>> >> >>> >>>> database handles state process created: 1 >>> >> >>> >>>> 2012-01-24 20:53:45|4138|vcld:REAPER(718)|VCL process exited >>> for >>> >> >>> >>>> reservation <unknown>, PID: 4978, signal: CHLD >>> >> >>> >>>> >>> >> >>> >>>> My limited understanding of PERL is at play here, but from my >>> >> >>> research >>> >> >>> >> it >>> >> >>> >>>> seems that updated versions of LWP::UserAgent do strict SSL >>> >> >>> certificate >>> >> >>> >>>> checking. (We do have a CA-issued SSL cert installed for the >>> VCL >>> >> Web >>> >> >>> >> front >>> >> >>> >>>> end.) >>> >> >>> >>>> >>> >> >>> >>>> >>> >> >>> >>>> >>> >> >>> >> >>> >> >>> >>> >> >>> http://stackoverflow.com/questions/74358/how-can-i-get-lwp-to-validate-ssl-server-certificates >>> >> >>> >>>> >>> >> >>> >>>> I'd very much appreciate any feedback from experts on the list. >>> >> >>> >>>> >>> >> >>> >>>> Many thanks, >>> >> >>> >>>> Mike >>> >> >>> >>>> >>> >> >>> >>>> >>> >> >>> >>>> On Tue, Jan 24, 2012 at 20:12, Mike Haudenschild < >>> >> m...@longsight.com >>> >> >>> >>> wrote: >>> >> >>> >>>> >>> >> >>> >>>>> I've been looking into this further, and I've found what >>> appears >>> >> to >>> >> >>> be >>> >> >>> >> a >>> >> >>> >>>>> missing PERL module (LWP::Protocol::https). I attempted to >>> >> install >>> >> >>> it >>> >> >>> >>>>> manually with CPAN, but I get two test errors. I've attached >>> the >>> >> >>> CPAN >>> >> >>> >>>>> error message immediately below, and the section of vcld.log >>> from >>> >> >>> the >>> >> >>> >>>>> moment I save the block allocation. >>> >> >>> >>>>> >>> >> >>> >>>>> Thanks to all, >>> >> >>> >>>>> Mike >>> >> >>> >>>>> >>> >> >>> >>>>> ------ >>> >> >>> >>>>> >>> >> >>> >>>>> t/apache....# Failed test 1 in t/apache.t at line 12 >>> >> >>> >>>>> # t/apache.t line 12 is: ok($res->is_success); >>> >> >>> >>>>> # Failed test 2 in t/apache.t at line 13 >>> >> >>> >>>>> # t/apache.t line 13 is: ok($res->content =~ /Apache Software >>> >> >>> >>>>> Foundation/); >>> >> >>> >>>>> t/apache....FAILED tests 1-2 >>> >> >>> >>>>> Failed 2/2 tests, 0.00% okay >>> >> >>> >>>>> Failed Test Stat Wstat Total Fail Failed List of Failed >>> >> >>> >>>>> >>> >> >>> >>>>> >>> >> >>> >> >>> >> >>> >>> >> >>> ------------------------------------------------------------------------------- >>> >> >>> >>>>> t/apache.t 2 2 100.00% 1-2 >>> >> >>> >>>>> Failed 1/1 test scripts, 0.00% okay. 2/2 subtests failed, >>> 0.00% >>> >> >>> okay. >>> >> >>> >>>>> make: *** [test_dynamic] Error 255 >>> >> >>> >>>>> /usr/bin/make test -- NOT OK >>> >> >>> >>>>> Running make install >>> >> >>> >>>>> make test had returned bad status, won't install without >>> force >>> >> >>> >>>>> >>> >> >>> >>>>> ------ >>> >> >>> >>>>> >>> >> >>> >>>>> >>> >> >>> >>>>> 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm: >>> >> >>> >> process(166)|owner >>> >> >>> >>>>> email: root@localhost >>> >> >>> >>>>> Use of uninitialized value in concatenation (.) or string at >>> >> >>> >>>>> /usr/local/vcl/bin/../lib/VCL/blockrequest.pm line 167 >>> >> (#1) >>> >> >>> >>>>> (W uninitialized) An undefined value was used as if it were >>> >> >>> already >>> >> >>> >>>>> defined. It was interpreted as a "" or a 0, but maybe it >>> was >>> >> a >>> >> >>> >>>>> mistake. >>> >> >>> >>>>> To suppress this warning assign a defined value to your >>> >> >>> variables. >>> >> >>> >>>>> >>> >> >>> >>>>> To help you figure out what was undefined, perl tells you >>> what >>> >> >>> >>>>> operation >>> >> >>> >>>>> you used the undefined value in. Note, however, that perl >>> >> >>> >> optimizes >>> >> >>> >>>>> your >>> >> >>> >>>>> program and the operation displayed in the warning may not >>> >> >>> >> necessarily >>> >> >>> >>>>> appear literally in your program. For example, "that >>> $foo" is >>> >> >>> >>>>> usually optimized into "that " . $foo, and the warning will >>> >> refer >>> >> >>> >> to >>> >> >>> >>>>> the concatenation (.) operator, even though there is no . >>> in >>> >> your >>> >> >>> >>>>> program. >>> >> >>> >>>>> >>> >> >>> >>>>> >>> >> >>> >>>>> |3518|blockrequest| ---- WARNING ---- >>> >> >>> >>>>> |3518|blockrequest| 2012-01-24 19 >>> >> >>> >> :40:35|3518|blockrequest|vcld:warning_handler(610)|Use >>> >> >>> >>>>> of uninitialized value in concatenation (.) or string at >>> >> >>> >>>>> /usr/local/vcl/bin/../lib/VCL/blockrequest.pm line 167. >>> >> >>> >>>>> |3518|blockrequest| ( 0) vcld, warning_handler (line: 610) >>> >> >>> >>>>> |3518|blockrequest| (-1) blockrequest.pm, process (line: 167) >>> >> >>> >>>>> |3518|blockrequest| (-2) vcld, make_new_child (line: 568) >>> >> >>> >>>>> |3518|blockrequest| (-3) vcld, main (line: 448) >>> >> >>> >>>>> >>> >> >>> >>>>> 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm: >>> >> >>> >> process(167)|help >>> >> >>> >>>>> address: >>> >> >>> >>>>> 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm: >>> >> >>> >> process(172)|updated >>> >> >>> >>>>> process flag on blocktime_id= 4 >>> >> >>> >>>>> 2012-01-24 19:40:35|3518|blockrequest|blockrequest.pm: >>> >> >>> >> process(192)|processing >>> >> >>> >>>>> blocktime_id= 4 pass 1 >>> >> >>> >>>>> 2012-01-24 19:40:35|3518|blockrequest|utils.pm: >>> >> >>> >> xmlrpc_call(9105)|argument_string= >>> >> >>> >>>>> XMLRPCprocessBlockTime 4 1 >>> >> >>> >>>>> 2012-01-24 19:40:35|3518|blockrequest|utils.pm: >>> >> mail(1268)|SUCCESS >>> >> >>> -- >>> >> >>> >>>>> Sending mail To: 0, PROBLEM -- vcld:die_handler(636)|test >>> >> >>> >>>>> >>> >> >>> >>>>> |3518|blockrequest| ---- CRITICAL ---- >>> >> >>> >>>>> |3518|blockrequest| 2012-01-24 19 >>> >> >>> >> :40:35|3518|blockrequest|vcld:die_handler(636)|Can't >>> >> >>> >>>>> locate object method "type" via package >>> >> >>> >> "RPC::XML::Client::send_request: >>> >> >>> >>>>> HTTP server error: Protocol scheme 'https' is not supported >>> >> >>> >>>>> (LWP::Protocol::https not installed)" (perhaps you forgot to >>> load >>> >> >>> >>>>> "RPC::XML::Client::send_request: HTTP server error: Protocol >>> >> scheme >>> >> >>> >> 'https' >>> >> >>> >>>>> is not supported (LWP::Protocol::https not installed)"?) at >>> >> >>> >>>>> /usr/local/vcl/bin/../lib/VCL/utils.pm line 9121. >>> >> >>> >>>>> |3518|blockrequest| ( 0) vcld, die_handler (line: 636) >>> >> >>> >>>>> |3518|blockrequest| (-1) utils.pm, xmlrpc_call (line: 9121) >>> >> >>> >>>>> |3518|blockrequest| (-2) blockrequest.pm, process_block_time >>> >> (line: >>> >> >>> >> 373) >>> >> >>> >>>>> |3518|blockrequest| (-3) blockrequest.pm, process (line: 193) >>> >> >>> >>>>> |3518|blockrequest| (-4) vcld, make_new_child (line: 568) >>> >> >>> >>>>> |3518|blockrequest| (-5) vcld, main (line: 448) >>> >> >>> >>>>> >>> >> >>> >>>>> 2012-01-24 19 >>> >> >>> >> :40:35|3518|blockrequest|State.pm:DESTROY(829)|VCL::blockrequest >>> >> >>> >>>>> destructor called, address: 96b7c1c >>> >> >>> >>>>> 2012-01-24 19 >>> >> :40:35|3518|blockrequest|State.pm:DESTROY(848)|number >>> >> >>> of >>> >> >>> >>>>> database handles state process created: 1 >>> >> >>> >>>>> 2012-01-24 19:40:35|3459|vcld:REAPER(718)|VCL process exited >>> for >>> >> >>> >>>>> reservation <unknown>, PID: 3518, signal: CHLD >>> >> >>> >>>>> >>> >> >>> >>>>> >>> >> >>> >>>>> >>> >> >>> >>>>> On Tue, Jan 24, 2012 at 12:05, Mike Haudenschild < >>> >> >>> m...@longsight.com >>> >> >>> >>> wrote: >>> >> >>> >>>>> >>> >> >>> >>>>>> Hello, VCL dev -- >>> >> >>> >>>>>> >>> >> >>> >>>>>> I've seen three instances of "relaim" errors on my VCL >>> instance >>> >> >>> today >>> >> >>> >> -- >>> >> >>> >>>>>> machines that vcld couldn't seem to reach, although they >>> >> appeared >>> >> >>> >> running >>> >> >>> >>>>>> on the ESXi console. >>> >> >>> >>>>>> >>> >> >>> >>>>>> It started when I began creating block allocations (which did >>> >> not >>> >> >>> >> appear >>> >> >>> >>>>>> to work). In both cases there seemed to be text in the log >>> >> >>> regarding >>> >> >>> >>>>>> incorrect SQL syntax. >>> >> >>> >>>>>> >>> >> >>> >>>>>> After the errors, the affected machines showed as "failed" in >>> >> the >>> >> >>> VCL >>> >> >>> >>>>>> front end, but eventually reloaded and appear to be working >>> >> fine. >>> >> >>> >>>>>> >>> >> >>> >>>>>> Regular, individual reservations appear to be working fine. >>> >> I've >>> >> >>> >>>>>> attached both snippets of log and would appreciate any >>> feedback. >>> >> >>> >>>>>> >>> >> >>> >>>>>> Many thanks, >>> >> >>> >>>>>> Mike >>> >> >>> >>>>>> >>> >> >>> >>>>> >>> >> >>> >>>>> >>> >> >>> >>>> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> Aaron Peeler >>> >> >>> >> Program Manager >>> >> >>> >> Virtual Computing Lab >>> >> >>> >> NC State University >>> >> >>> >> >>> >> >>> >> All electronic mail messages in connection with State business >>> which >>> >> >>> >> are sent to or received by this account are subject to the NC >>> Public >>> >> >>> >> Records Law and may be disclosed to third parties. >>> >> >>> >> >>> >> >>> >>> >> >>> >>> >> >> >>> >> >>> > > > > -- > Aaron Peeler > Program Manager > Virtual Computing Lab > NC State University > > All electronic mail messages in connection with State business which > are sent to or received by this account are subject to the NC Public > Records Law and may be disclosed to third parties.
