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.

Reply via email to