On 01/16/2015 08:23 AM, Ulrich Windl wrote: > Hello! > > Today we rebooted our FibreChannel storage that is accessed via iSCSI. Since > then (the storage is up again) syslog is filled with messages like these: > ... > Jan 16 14:30:31 o1 multipathd: VM-E2: sdbs - tur checker reports path is down > Jan 16 14:30:31 o1 multipathd: cLVM-E2: sdbw - tur checker reports path is > down > Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01) > Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01) > Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01) > Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01) > Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01) > Jan 16 14:30:31 o1 iscsid: conn 0 login rejected: target error (03/01)
This error code comes from the target and means "The iSCSI service or target is not currently operational." > ... > > Shortly after the storage was down I saw these messages in syslog: > Jan 16 13:22:01 o1 kernel: [781809.177434] device-mapper: multipath: Failing > path 68:192. > Jan 16 13:22:02 o1 multipathd: sdbi: No fc_remote_port device for > 'rport-24:0-0' > Jan 16 13:22:03 o1 multipathd: sdd: No fc_remote_port device for 'rport-5:0-0' > > So I guess multipathd tries to remove the down device, but fails to realize > that it's an iSCSI (not FC) device. Yeah, I think this is just a bug in the multipath code, but it can be ignored. It looks like we just log this error when we cannot set some fc settings like dev_loss and then just move on. I am not a expert in the multipath tools code though, so best to ask dm-devel or suse if you want to know for sure for your version of multipath-tools. > So is this (removal of stale devices) possible? > > I tried a "rescan-scsi-bus.sh -r", but still I see these: > Jan 16 14:34:27 o1 iscsid: conn 0 login rejected: target error (03/01) > Jan 16 14:34:27 o1 iscsid: conn 0 login rejected: target error (03/01) > > (The iSCSI gateway was never restarted; just the FC- backend) If the iSCSI gateway never fully restarted then the login rejection errors are expected. The rescan-bus-scsi.sh script will remove the LUs (/dev/sdXs), but it will not remove the isccsi sessions. To do this run: iscsiadm -m node -T yourtarget -p ip --logout or to logout/kill everything do: iscsiadm -m session --logout Those iscsiadm commands will do both the device/LU removal and iscsi session removal so you only to run it. If you want to login later then you need to run iscsiadm -m node -T yourtarget -p ip --login or restart the iscsi service using whatever command suse recommends. > > Is this a problem in open-iscsi (SLES11 SP3: open-iscsi-2.0.873-0.23.1)? > (After Reboot everything looked clean again) > > Regards, > Ulrich > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
