What steps will reproduce the problem?
Compile conman with freeipmi support and debug informations (configure
--enable-debug).
Launch conmand with a console configured to use freeimpi.
Make sure that this BMC conman will try to connect to does not respond.
What is the expected output? What do you see instead?
The expected result should be a loop of retries, in increasing time
intervals up to a maximum of IPMI_MAX_TIMEOUT (as seen in server-ipmi.c:
fail_ipmi_connect).
What we can see is the failed assert:
INFO: Unable to connect to <bmc1> via IPMI to console [host1]:
connection timeout
Reconnect attempt to <bmc1> via IPMI for [host1] in 60s.
conmand: server-ipmi.c:451: create_ipmi_ctx: Assertion `ipmi->aux.ipmi.ctx
== ((void *)0)' failed.
ERROR: Terminating on signal=6
What version of the software are you using? On what operating system?
Last released conman-0.2.5
Last released FreeIPMI 0.8.6
Fedora core 12.
Please provide any additional information below.
The problem here has been tracked down to an inconsistancy in the state of
the ipmi object. After the first failed attempt, the fail_ipmi_connect
function is called and issues ipmi->aux.ipmi.state = CONMAN_IPMI_DOWN.
It then reprograms a new connection try in 60s, without touching
ipmi->aux.ipmi.ctx.
When retrying to connect, connect_ipmi_obj is called. As the state is down,
it calls initiate_ipmi_connect. The first action of this function is to
call create_ipmi_ctx, which according to the assert should not be called on
an already existing context.
The proposed attached patch adds a call to ipmiconsole_ctx_destroy to
fail_ipmi_connect, in order to maintain a consitency between the
ipmi->state and the ctx allocation: a state at CONMAN_IPMI_DOWN does not
require a context. This moreover avoids to submit the same contexts to the
ipmiconsole engine twice.
Original issue reported on code.google.com by matthieu...@bull.net on 2 Jun 2010 at 3:41
Original issue reported on code.google.com by
matthieu...@bull.net
on 2 Jun 2010 at 3:41Attachments: