+++ This bug was initially created as a clone of Bug #430810 +++ Description of problem: If I remove a target on the isns sever, then rerun discovery with iscsiadm the record for the target that was removed is not deleted. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Record for deleted target should be removed. Additional info: -- Additional comment from rom.org on 2008-07-30 09:45 EST -- Excerpt from strace of iscsiadm: unlink("/var/lib/iscsi/send_targets/10.4.10.55,3260/iqn.2003-10.com.lefthandnetworks:lhsan:28:www-root,10.4.10.55,3260,1,default") = -1 EISDIR (Is a directory) write(2, "iscsiadm: ", 10) = 10 write(2, "Could not remove link /var/lib/i"..., 147) = 147 Note, this particular iscsi target was one that was scanned at install time by anaconda, ones scanned via iscsiadm command later appear to be symlinks in the same directory (as iscsiadm appears to expect). -- Additional comment from mchristi on 2008-07-31 12:46 EST -- Hi, I am not sure what you are reporting on here. This bugzilla was just for isns discovery, because the removal feature was not implemented. Are you having trouble with just targets/portals found with send targets discovery? What is the exact problem? As far as symlink vs dir goes, it should be ok, because iscsiadm supports both layouts. Is iscsiadm failing and logging something about this? You can also run iscsiadm ..... -d 8 to get lots of debug info. Let me know what is wrong, and run iscsiadm with -d 8 and I can help more. -- Additional comment from rom.org on 2008-07-31 13:40 EST -- The original notes on the bug report talk about rerunning discovery with iscsiadm, and a target that was removed not being deleted. Looked to be the exact same issue that was happening for me, thus the additional information was related, and may help to nail down where the bug actually is. # iscsiadm -m discovery -t st -p 10.4.10.55:3260 iscsiadm: Could not remove link /var/lib/iscsi/send_targets/10.4.10.55,3260/iqn.2003-10.com.lefthandnetworks:lhsan:28:www-root,10.0.30.7,3260,1,default err 21 iscsiadm: Could not delete node /var/lib/iscsi/nodes/iqn.2003-10.com.lefthandnetworks:lhsan:28:www-root/10.4.10.55,3260/default -- Additional comment from mchristi on 2008-08-01 05:05 EST -- (In reply to comment #3) > The original notes on the bug report talk about rerunning discovery with > iscsiadm, and a target that was removed not being deleted. Looked to be the > exact same issue that was happening for me, thus the additional information was > related, and may help to nail down where the bug actually is. Ah I see, it was my fault. I did not describe the problem right in the original bugzilla comment. This bugzilla is just for isns discvoery not removing targets correctly. For isns, we did not implement this feature at all, so if the isns server told us about targetA and targetB, then only tells us about TargetA, the initiator's isns discovery code just leaves targetB on purpose. For what you hit below it looks like a bug in the sendtargets code where we did try to handle the case where sendtargets returns different targets. Let me make a new bugzilla for your issue. > > # iscsiadm -m discovery -t st -p 10.4.10.55:3260 > iscsiadm: Could not remove link > /var/lib/iscsi/send_targets/10.4.10.55,3260/iqn.2003-10.com.lefthandnetworks:lhsan:28:www-root,10.0.30.7,3260,1,default > err 21 > iscsiadm: Could not delete node > /var/lib/iscsi/nodes/iqn.2003-10.com.lefthandnetworks:lhsan:28:www-root/10.4.10.55,3260/default
Could you tell me what version of iscsi-initiator-utils you are using, and what version of RHEL5? And is the portal at 10.0.30.7,3260 on the target iqn.2003-10.com.lefthandnetworks:lhsan:28:www-root, no longer being returned by sendtargets? Some versions of iscsiadm, will try to upgrade older formats to newer ones.
Could you also run iscsiadm with -d 8 and send the output. I tied replicating this here, by first making records with the old tools that did not use links. Then I used the current tool, iscsi-initiator-utils-6.2.0.868-0.7, to do discovery to the same discvoery address, and it worked ok. I also tried removing targets and doing discvoery with the new tools but using the old nonlink layout and that worked ok.
Created attachment 313764 [details] iscsiadm -d8 output Slightly censored to protect information about who's network this is, and the network layout. Changed IP addresses / hostnames / iscsi target names.
Box was installed as 5.1 and was upgraded to 5.2 (it's is a CentOS install, for which RH is upstream, so in theory, a bug in one should be in both) iscsi-initiator-utils-6.2.0.868-0.7.el5 is installed. The target's in question that it is generating an error attempting to delete, where target that it scanned during install time (by anaconda), so what ever version of iscsi-initiator-utils is included in the 5.1 installer. I do know how to fix the issue manually (by deleting the directory manually), and I did do this on one of the other servers, but, I would like to contribute when possible.
(In reply to comment #4) > Box was installed as 5.1 and was upgraded to 5.2 (it's is a CentOS install, for > which RH is upstream, so in theory, a bug in one should be in both) > Yeah, it should be in both. Let me try this here with anaconda installing it the initial db and using those versions. Thanks for the info. I am adding this on the todo for the next RHEL version.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
This did not make 5.3, due to a lack of resources. Proposing for 5.4.
Moving to 5.5.