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,


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
    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

|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
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
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)

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

Reply via email to