Bug 177341 - iscsi-ls -l hangs indefinately if target is unreachable
iscsi-ls -l hangs indefinately if target is unreachable
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: iscsi-initiator-utils (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike Christie
: Reopened
Depends On:
Blocks: 181409 195300
  Show dependency treegraph
 
Reported: 2006-01-09 16:21 EST by Dave Wysochanski
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2007-0305
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-01 18:59:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
simpleton patch to check session state before issuing scsi_id commands (586 bytes, patch)
2006-01-09 16:21 EST, Dave Wysochanski
no flags Details | Diff

  None (edit)
Description Dave Wysochanski 2006-01-09 16:21:30 EST
Description of problem:
If a target is mapped with LUNs to a linux machine then it becomes unreachable,
"iscsi-ls -l" will hang indefinately.  This is different than the RHEL3 and
prior initiators' behavior.  Not sure if this difference is intentional, but
if not, it's probably good that the command doesn't hang indefinately.  Mike,
comments/thoughts?

Apologies for not filing this bugzilla earlier as we've known this for a long time.


Version-Release number of selected component (if applicable):
RHEL4 U3 beta

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:
"iscsi-ls -l" hangs indefinately

Expected results:
Not indefinate hang.  Either timeout or print "UNKNOWN" for info obtained via
scsi_id.

Additional info:

Attached simpleton patch checks session state and if not connected prints
"UNKNOWN".
Comment 1 Dave Wysochanski 2006-01-09 16:21:31 EST
Created attachment 122972 [details]
simpleton patch to check session state before issuing scsi_id commands
Comment 3 Mike Christie 2006-01-10 11:59:18 EST
The patch is ok.

Are you sure you cannot cause this in RHEL3 though?
Comment 4 Dave Wysochanski 2006-01-10 18:53:36 EST
Don't have a rhel3 machine but not as I recall since the mechanism is ioctls
in rhel3 and I think cached info.  I don't recall it ever hanging for me.  In
rhel4 we're using scsi_id, which issues a SCSI cmd that needs to complete each
time to get the info.
Comment 5 Mike Christie 2006-01-10 19:00:55 EST
Where would it be cached? Could we use that same info in RHEL4? Can we get
everything from sysfs but the uuid?
Comment 6 Dave Wysochanski 2006-01-11 12:28:26 EST
My memory must be going (it's been a while since I looked at RHEL3).  Looked at
the RHEL3 code and it tells all.  Can't see how it wouldn't hang in RHEL3 as
well since it uses SCSI_IOCTL_SEND_COMMAND to send inquiries for the same page
80/83 data as RHEL4 gets from scsi_id.

Interestingly, RHEL4 scsi_id uses SG_IO, and a timeout of 5 seconds.  This gets
overridden though by iscsi's default ConnFailTimeout in the case of a target
cable pull or something like that - iscsi just keeps trying forever.  One can't
have their cake and eat it too.  If you set ConnFailTimeout to a finite value
"iscsi-ls -l" will fail and you'll get something like this:
DEVICE DETAILS:
---------------
LUN ID : 0
  Vendor: NETAPP   Model: LUN              Rev: 0.2
  Type:   Direct-Access                    ANSI SCSI revision: 04
6:0:0:0: sg_io failed status 0x8 0x2 0x0 0x0
6:0:0:0: Unable to get INQUIRY vpd 1 page 0x83.
  page83 type0:
6:0:0:0: cannot open /dev/tmp-scsi-maj8-min32-29322: No such device or address
  page80:
  Device: /dev/sdc
*******************************************************************************

We could "fix" RHEL3 by switching to SG_IO and using a timeout but then you have
to deal with sd->sg mapping.  Then I think you have the same connfailtimeout
issue if you didn't want it to hang.  Might not be worth doing.

Maybe the simple route is the way to go (check whether session is up before
trying scsi_id, and/or in the case of RHEL3, issuing inquiries), that is, if we
agree hanging is a bad thing and worth fixing.  If there's no inconsistency, and
you're not hearing other complaints, maybe it's not worth changing the behavior
at all.

I guess what initially made me think it's probably not good that it hangs was
that all the earlier sourceforge drivers never hung - they didn't get the page
80/83 data either though but only displayed LUN #'s.  They truly did use cached
info from the driver (the 3.4.x and prior drivers), which is probably what I was
thinking of when I made the untrue claim in #4 about RHEL3.
Comment 7 Mike Christie 2006-01-11 13:51:00 EST
ok thanks for looking into that. Let's merge your patch for RHEL4. Let me dig
into RHEL3 stuff a little more.
Comment 9 Dave Wysochanski 2006-01-13 10:46:30 EST
Just to let you know, there is actually one use case for this bug I can think of
off the top of my head - mainly for support people.  We have data collection
scripts that run on the linux host for our support people to avoid a lot of the
back and forth of "which version of this are you running" conversations.  One of
these scripts runs "iscsi-ls -l".  If a customer is having problems and this
command hangs indefinately, it will probably not help the situation.

If you feel this is use case is beyond the scope of iscsi-ls, or some other use
case is in conflict and/or supercedes it, please let me know.

Thanks.
Comment 14 Red Hat Bugzilla 2006-08-10 17:54:59 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0495.html
Comment 15 Mike Christie 2007-04-09 14:46:18 EDT
There was a mixup where the patch for this bug did not get into RHEL 4.4. I am
reopening to put it in 4.5.
Comment 19 Red Hat Bugzilla 2007-05-01 18:59:27 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0305.html

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