Hide Forgot
Description of problem: when iscsid is down and the command - iscsiadm -m discoverydb -t sendtargets -p X.X.X.X:3260 --discover is initiated, the shell is flooded with: " iscsiadm: iscsid is not running. Could not start it up automatically using the startup command in the /etc/iscsi/iscsid.conf iscsid.startup setting. Please check that the file exists or that your init scripts have started iscsid. " and after 2 minutes cached targets is being displayed instead of exit message 20 = "ISCSI_ERR_ISCSID_NOTCONN - could ont connect to iscsid." Version-Release: iscsi-initiator-utils-6.2.0.872-16.el6.x86_64 How reproducible: 1)stop iscsid. 2)run the command.
I cannot replicate this one here. 1. Do you have anything in the /etc/iscsi/iscsid.conf iscsid.startup setting? 2. Is the iscsiadm exit code 0 then? 3. Could you send all the iscsiadm output? 4. Have you done discovery to X.X.X.X:3260 already or is this the first time? 5. When you say flooded do you mean you see it twice or is it constantly getting printed for 2 minutes? 6. Are you using iscsi ifaces?
Hi Mike, Your right, i forgot to mention some important information. The full scenario: 1) initiate discovery : iscsiadm -m discoverydb -t sendtargets -p X.X.X.X:3260 --discover 2) add iface: iscsiadm -m iface -o new -I X 3) update iface initiator : iscsiadm -m iface -o update -I X -n iface.initiatorname -v X 4) stop iscsid 5) initiate discovery again: iscsiadm -m discoverydb -t sendtargets -p X.X.X.X:3260 --discover - and view the results - the output is constantly getting printed - iscsid.conf settings: node.startup = manual node.session.timeo.replacement_timeout = 120 node.conn[0].timeo.login_timeout = 15 node.conn[0].timeo.logout_timeout = 15 node.conn[0].timeo.noop_out_interval = 5 node.conn[0].timeo.noop_out_timeout = 5 node.session.initial_login_retry_max = 4 node.session.cmds_max = 128 node.session.queue_depth = 32 node.session.iscsi.InitialR2T = No node.session.iscsi.ImmediateData = Yes node.session.iscsi.FirstBurstLength = 262144 node.session.iscsi.MaxBurstLength = 16776192 node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768
I ran the same commands but still am not hitting it. Do you know if this just started in .16 or did it happen in RHEL 6.0's iscsi tools too? And do you have iscsid.startup = /etc/rc.d/init.d/iscsid force-start in /etc/iscsi/iscsid.conf? Could you give me access to your box where this is happening?
Sorry i did not test it on other versions. lets sync on irc and ill give you access to my box. #tlv
Hi Mike i have added two steps that may be the reason why you didnt manage to reproduce the issue. can you try please reproduce it with the current steps: 1) initiate discovery : iscsiadm -m discoverydb -t sendtargets -p X.X.X.X:3260 --discover 2) add iface: iscsiadm -m iface -o new -I X 3) update iface initiator : iscsiadm -m iface -o update -I X -n iface.initiatorname -v X 4) iscsiadm -m discoverydb -t sendtargets -p 10.35.64.25:3260 -I X -o new 5) add another user follow the steps above. 6) stop iscsid 7) initiate discovery again: iscsiadm -m discoverydb -t sendtargets -p X.X.X.X:3260 --discover - and view the results
Still was not able to hit it. What is your nick on irc? Some comments below: (In reply to comment #5) > 4) iscsiadm -m discoverydb -t sendtargets -p 10.35.64.25:3260 -I X -o new Were you wanting to bind the iface to the discovery record? We do not support thet. The -I here does not do anything. It is just ignored, because we are not doing discovery. So that command just basically creates a discovery record. > > 7) initiate discovery again: iscsiadm -m discoverydb -t sendtargets -p > X.X.X.X:3260 --discover - and view the results If you wanted to bind target portals found during discovery to ifaces then you can pass it in here iscsiadm -m discoverydb -t sendtargets -p X.X.X.X:3260 --discover -I iface0 -I iface1 or by default if no ifaces are passed in but there are some created that are using iscsi_tcp then iscsiadm will use them.
I have sent you an e-mail with the login information to my box.
Thanks David. It looks like a combo of issues. I should be able to upload a rpm in a couple of hours. A question for you guys. 1. Do you know how iscsid got killed but the iscsid serivce did not shutdown cleanly? 2. I was just wondering why you do not have the iscsid.startup set in /etc/iscsi/iscsid.conf? Do you guys just not like the feature or were you guys testing with it not set? I think it was added in 6.0 to handle the case where iscsid was not running. It basically just starts iscsid for iscsiadm.
Hey David, It looks like you are not getting cached targets. The iscsiadm command looks like it is working using the defaults settings, and that is why you get 0 for the return code. The initial "iscsiadm: iscsid is not running" errors are from when iscsiadm contacts iscsid to get the default settings. That fails, so iscsiadm uses the hard coded defaults. iscsiadm then contacts iscsid to get the initiatorname, but because the ifaces have an initiator name we ignore the error and use the iface inames. We then do sendtargets discovery and print out what was found. The discovery is successful and so we return 0. I did find one bug, where if the iface iname is not set, then we return INVAL instead of ISCSID_NOTCONN. I have fixed that. I also fixed it where we contact iscsid for the iname if the iface has a iname set. The behavior where we drop down to the hard coded defaults is documented in the iscsi readme, so I do not think I can change the behavior now. However, how about just making the errors more quiet? I could not replicate the 2 minute wait issue.
(In reply to comment #9) > > I could not replicate the 2 minute wait issue. Ignore this. I can see how we can hit it.
Mike, Can provide the reproduce step you mentioned in Comment #10?
Hey Gris, You basically just kill iscsid before running a discovery command. Here is what I did: iscsiadm -m iface -o new -I myiface iscsiadm -m discovery -t sendtargets -p ip -I myiface killall iscsid iscsiadm -m discovery -t sendtargets -p ip -I myiface The last iscsiadm run will then spit out a lot of error messages over and over.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available. The official life cycle policy can be reviewed here: http://redhat.com/rhel/lifecycle This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL: https://access.redhat.com/