That does sound like a bug in STGT. But a workaround could be if you upgrade to 1.0.38 or later. This probably means you have to compile tgtd from sources since I doubt any distro has picked up it yet. >From that version we have support in tgtd to send target initiated NOPs to the initiator which will automatically remove and clear out any dead connections. It is disabled by default but you can enable it globally from the tgtd commandline : tgtd --iscsi nop_interval=5,nop_count=6 Or you can also set it at runtime per target using the tgtadm command. Please see the manpage for tgtd and tgtadm for version 1.0.38 or later for the exact syntax. On Sat, Aug 17, 2013 at 9:14 AM, Alban Rrustemi <alban@xxxxxxxxxxx> wrote: > Hi everyone, > > My name is Alban and I'm trying to learn a bit more on STGT. I've > started using the iSCSI component and it's mostly been a good > experience, although recently I started running into some > difficulties. > > Firstly, I wasn't sure if this is the best place to ask some technical > questions - apologies in advance if this is not the right audience. > Any pointers to the right direction would be greatly appreciated. > > I've got an Ubuntu Server 12.04 (x64) installation with the default > version of stgt installed (i.e: Version: 1:1.0.17-1ubuntu2). This > installation has three iSCSI targets configured with one LUN per > target. No custom ACL configuration is present. > > On the other hand, there are three Windows machines (Windows 7 and > above), from where these three iSCSI targets are accessed from. The > standard Microsoft Windows iSCSI Initiator is used for this purpose. > > Every once in a while, after successfully disconnecting initiators and > removing the connected LUNs, targets don't seem to end up in a clean > state. What I mean by this is that some initiator connections remain > present in the target even after disconnecting initiators. As a > consequence, this prevents the targets from being removed. In such > situations, the target information may look like this: > > Target 3: strauss.server3:for.all > System information: > Driver: iscsi > State: ready > I_T nexus information: > I_T nexus: 15 > Initiator: iqn.1991-05.com.microsoft:server3 > Connection: 1 > IP Address: 192.168.1.42 > I_T nexus: 16 > Initiator: iqn.1991-05.com.microsoft:server3 > Connection: 1 > IP Address: 192.168.1.42 > ... > I_T nexus: 21 > Initiator: iqn.1991-05.com.microsoft:server3 > Connection: 1 > IP Address: 192.168.1.42 > LUN information: > LUN: 0 > Type: controller > SCSI ID: IET 00030000 > SCSI SN: beaf30 > Size: 0 MB, Block size: 1 > Online: Yes > Removable media: No > Readonly: No > Backing store type: null > Backing store path: None > Backing store flags: > Account information: > ACL information: > > > I had a look at the iSCSI server logs and I see reports that the iSCSI > server fails to close the connections: > > When I list the connections with the following command: >> sudo tgtadm --lld iscsi --op show --mode conn --tid 3 > > I get to see all the connections reported above. However, when I > attempt to remove/close them: >> sudo tgtadm --lld iscsi --op delete --mode conn --tid 3 --sid 21 --cid 1 > > the command seems to succeed (i.e. it doesn't print any error > messages) but the actual connection is not removed. The corresponding > logs (/var/log/syslog) suggest that these connections are somehow > unaccounted for by tgt: > > Aug 16 03:43:34 STRAUSS tgtd: conn_close_admin(235) close 15 1 > Aug 16 03:43:34 STRAUSS tgtd: tgt_event_modify(213) Cannot find event 20 > Aug 16 03:43:34 STRAUSS tgtd: iscsi_event_modify(413) tgt_event_modify failed > > The same log keeps reporting that a tcp connection is broken: > > Aug 16 03:40:49 STRAUSS tgtd: iscsi_tcp_show(390) Transport endpoint > is not connected > > Looking at the logs on the Windows end, the initiator (iScsiPrt) > reports many difficulties with timeouts. The event log has many > entries that contain the following chain of events: > >> (Warn) The description for Event ID 129 from source iScsiPrt cannot be found. ... >> (Error) Initiator sent a task management command to reset the target. The target name is given in the dump data. >> (Error) Target failed to respond in time to a Task Management request. >> (Error) Target did not respond in time for a SCSI request. The CDB is given in the dump data. >> (Error) Can not Reset the Target or LUN. Will attempt session recovery. > > I've got two questions about the situation above: > 1) is there any way to remove the described dangling connections from > the target? Failing this, is there a way to forcefully remove a target > that has such connections? > 2) the initiator timeouts seem to be reported even when the iSCSI > server host is not loaded. I've been looking for information about any > performance tuning of the iSCSI server that would reduce these timeout > issues, but have had no luck so far. Is there anything that can be > done to reduce such timeouts? > > Many thanks, > Alban > -- > To unsubscribe from this list: send the line "unsubscribe stgt" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
