Bug 857106 - ipmitool sol sessions stop responding
Summary: ipmitool sol sessions stop responding
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: ipmitool
Version: 14
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ales Ledvinka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-13 15:12 UTC by Andrew J. Schorr
Modified: 2016-09-20 04:34 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-01-26 09:30:41 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
rc1 (7.83 KB, patch)
2012-11-29 01:15 UTC, Ales Ledvinka
no flags Details | Diff

Description Andrew J. Schorr 2012-09-13 15:12:57 UTC
Description of problem: I use ipmitool with conserver to manage remote Fedora systems.  This works fine initially, but eventually the ipmitool session becomes unresponsive.  When a system crashes, it is helpful to have a log of any message that may have been printed on the console.  But I am not getting these messages because the SOL session has frozen.  A restart fixes the problem.  Using the usesolkeepalive gives even worse results than the default keepalive method.


Version-Release number of selected component (if applicable):
1.8.11

How reproducible:
Run "ipmitool -I lanplus -H <host> sol activate" and wait a while.

Steps to Reproduce:
1. Run "ipmitool -I lanplus -H <host> sol activate"
2. Wait a while for the session to become unresponsive.
3. Try adding the "usesolkeepalive" argument and see that it does not help.
  
Actual results:
The session freezes after a while.

Expected results:
The keepalive behavior should detect that the session has become unresponsive, and the program should exit or reinitialize the session.

Additional info:

Comment 1 Ales Ledvinka 2012-11-21 17:14:04 UTC
I reproduced something what might be fixed but I am not sure that we both observe same problem/protocol and target host capabilities.

What have I reproduced can be called: "The sol complains of send error forever until input activity."

scenario: activate sol session, add output filtering drop rule for the ipmitool socket, deactivate the session using other ipmitool instance, remove the output drop filtering rule

--- investigation comments below (current, not f14)
I see the -N and -R command line options might be duplicate with the SOL_KEEPALIVE_TIMEOUT and SOL_KEEPALIVE_RETRIES and also with the MAX_SOL_RETRY (in the ipmi_sol_red_pill)
And the _keepalive_retries is really never used for anything.
That the ipmi_sol_red_pill() never receives anything else then 0 from both either the ipmi_sol_keepalive_using_getdeviceid() or ipmi_sol_keepalive_using_sol()

the send_sol returns  NULL / rsp pointer
the keepalive returns  -1  /  0

For inactive session keepalive with get device id command there is probably no indication of session active/inactive
But in case of network or target host issues when there is no reply the ipmitool should be able to terminate.

counter scenario for the change of this behavior might be setup with console server where admin can not reach the console server and deactivates it's session directly at the managed target for manual override. the buggy behaviour prevents race in such conditions.

Comment 2 Ales Ledvinka 2012-11-29 01:15:45 UTC
Created attachment 653908 [details]
rc1

Comment 3 Jan Kurik 2015-12-22 11:35:17 UTC
This bug is currently assigned to an unsupported release. If you think this bug is still valid and should remain open, please re-assign it to a supported release (F22, F23) or to rawhide.

Bugs which will be assigned to an unsupported release are going to be closed as EOL (End Of Life) on January 26th, 2016.


Note You need to log in before you can comment on or make changes to this bug.