On Monday, August 7, 2017 at 2:35:26 PM UTC-7, Bob Marris wrote: > > I'm running my initiator's root partition via open-iscsi to an IET target. > > I'm testing failure scenarios, and in the event of a target reboot (or > daemon restart) my initiator seems to hang. I was hoping it would be able > to recover and just carry on running once the target came back. Since this > is my root partition I can't see any logs once it hangs.... > > I've increased node.session.timeo.replacement_timeout. > > I've also added "discovery.sendtargets.use_discoveryd = Yes" in > /etc/iscsi/send_targets/192.168.1.5,3260/st_config, thinking that it > would allow the initiator to rediscover/login to the target when it comes > back up. > > I do not believe having your target rediscovered is the right approach and is likely just mucking things up. I suggest you reset this back to default, until you figure out the issue.
> Is it my initiator configuration or somehow a failing of IET at the target > side? > > > My settings at the initiator end are: > > pi@homeauto:/etc/iscsi $ sudo iscsiadm -m node -T > iqn.2017-07.eu.bobta:domoticz -p 192.168.1.5 > # BEGIN RECORD 2.0-873 > node.name = iqn.2017-07.eu.bobta:domoticz > node.tpgt = 1 > node.startup = automatic > node.leading_login = No > iface.hwaddress = <empty> > iface.ipaddress = <empty> > iface.iscsi_ifacename = default > iface.net_ifacename = <empty> > iface.transport_name = tcp > iface.initiatorname = <empty> > iface.bootproto = <empty> > iface.subnet_mask = <empty> > iface.gateway = <empty> > iface.ipv6_autocfg = <empty> > iface.linklocal_autocfg = <empty> > iface.router_autocfg = <empty> > iface.ipv6_linklocal = <empty> > iface.ipv6_router = <empty> > iface.state = <empty> > iface.vlan_id = 0 > iface.vlan_priority = 0 > iface.vlan_state = <empty> > iface.iface_num = 0 > iface.mtu = 0 > iface.port = 0 > node.discovery_address = 192.168.1.5 > node.discovery_port = 3260 > node.discovery_type = send_targets > node.session.initial_cmdsn = 0 > node.session.initial_login_retry_max = 8 > node.session.xmit_thread_priority = -20 > node.session.cmds_max = 128 > node.session.queue_depth = 32 > node.session.nr_sessions = 1 > node.session.auth.authmethod = CHAP > node.session.auth.username = bob > node.session.auth.password = ******** > node.session.auth.username_in = <empty> > node.session.auth.password_in = <empty> > node.session.timeo.replacement_timeout = 1200 > node.session.err_timeo.abort_timeout = 15 > node.session.err_timeo.lu_reset_timeout = 30 > node.session.err_timeo.tgt_reset_timeout = 30 > node.session.err_timeo.host_reset_timeout = 60 > node.session.iscsi.FastAbort = Yes > node.session.iscsi.InitialR2T = No > node.session.iscsi.ImmediateData = Yes > node.session.iscsi.FirstBurstLength = 262144 > node.session.iscsi.MaxBurstLength = 16776192 > node.session.iscsi.DefaultTime2Retain = 0 > node.session.iscsi.DefaultTime2Wait = 2 > node.session.iscsi.MaxConnections = 1 > node.session.iscsi.MaxOutstandingR2T = 1 > node.session.iscsi.ERL = 0 > node.conn[0].address = 192.168.1.5 > node.conn[0].port = 3260 > node.conn[0].startup = automatic > node.conn[0].tcp.window_size = 524288 > node.conn[0].tcp.type_of_service = 0 > node.conn[0].timeo.logout_timeout = 15 > node.conn[0].timeo.login_timeout = 15 > node.conn[0].timeo.auth_timeout = 45 > node.conn[0].timeo.noop_out_interval = 0 > node.conn[0].timeo.noop_out_timeout = 0 > node.conn[0].iscsi.MaxXmitDataSegmentLength = 0 > node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144 > node.conn[0].iscsi.HeaderDigest = None > node.conn[0].iscsi.DataDigest = None > node.conn[0].iscsi.IFMarker = No > node.conn[0].iscsi.OFMarker = No > # END RECORD > > Any help would be very much appreciated! > It looks like you are using CHAP? That shouldn't be an issue, but to simplify things you might want to remove that. I tested using iet as a target on SLE 12 SP1 and open-iscsi initiator on SLE 12 SP2. I ran a "dd" to read all the blocks on the iscsi target from the inititator, as well as running a "mkfs.ext3". Then I restarted the iet daemon. Both IO streams paused then continued. In other words, I cannot reproduce your issue. Can you do some testing? When the system hangs, is it the initiator or the target? You should be able to log into the target from another (different) initiator to see if the target's still working. You can also enable debugging on the target and the initiator to see what's happening when your hang occurs. I would suggest testing by using your iscsi target as a *non-root* disc. If it's your root disc and you have issues, you can't debug them very easily if you're using it as your root disc. -- Lee Duncan -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
