Bug 864036 - iSCSI session are not restored after reboot
Summary: iSCSI session are not restored after reboot
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: iscsi-initiator-utils
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: rc
: ---
Assignee: Chris Leech
QA Contact: Bruno Goncalves
URL:
Whiteboard:
: 958864 (view as bug list)
Depends On:
Blocks: 883874 1080147
TreeView+ depends on / blocked
 
Reported: 2012-10-08 12:16 UTC by Bruno Goncalves
Modified: 2021-09-03 13:47 UTC (History)
9 users (show)

Fixed In Version: iscsi-initiator-utils-6.2.0.873-7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 10:52:23 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Bruno Goncalves 2012-10-08 12:16:16 UTC
Description of problem:
iscsid do not login automatically on discovered portals after reboot.

Version-Release number of selected component (if applicable):

iscsi-initiator-utils-6.2.0.872-18.el7.x86_64

uname -r
3.6.0-0.28.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Discovery portals
iscsiadm -m discovery -t st -p "na3170b.lab.bos.redhat.com" -I default  -P1
Target: iqn.1992-08.com.netapp:sn.151753773
	Portal: 10.16.41.222:3260,1
		Iface Name: default
	Portal: 10.16.43.127:3260,1
		Iface Name: default

2.Login to portals
iscsiadm -m node -l
Logging in to [iface: default, target: iqn.1992-08.com.netapp:sn.151753773, portal: 10.16.41.222,3260] (multiple)
Logging in to [iface: default, target: iqn.1992-08.com.netapp:sn.151753773, portal: 10.16.43.127,3260] (multiple)
Login to [iface: default, target: iqn.1992-08.com.netapp:sn.151753773, portal: 10.16.41.222,3260] successful.
Login to [iface: default, target: iqn.1992-08.com.netapp:sn.151753773, portal: 10.16.43.127,3260] successful.

iscsiadm -m session
tcp: [1] 10.16.41.222:3260,1 iqn.1992-08.com.netapp:sn.151753773
tcp: [2] 10.16.43.127:3260,1 iqn.1992-08.com.netapp:sn.151753773


3.reboot

4. check sessions after reboot
iscsiadm -m session
iscsiadm: No active sessions.

5. Manual login works
iscsiadm -m node -l
Logging in to [iface: default, target: iqn.1992-08.com.netapp:sn.151753773, portal: 10.16.41.222,3260] (multiple)
Logging in to [iface: default, target: iqn.1992-08.com.netapp:sn.151753773, portal: 10.16.43.127,3260] (multiple)
Login to [iface: default, target: iqn.1992-08.com.netapp:sn.151753773, portal: 10.16.41.222,3260] successful.
Login to [iface: default, target: iqn.1992-08.com.netapp:sn.151753773, portal: 10.16.43.127,3260] successful.



  
Actual results:
no iSCSI session

Expected results:
sessions should be restored after reboot

Additional info:

Comment 4 Bruno Goncalves 2013-03-19 15:25:19 UTC
Problem is still reproducible with:

rpm -q iscsi-initiator-utils
iscsi-initiator-utils-6.2.0.873-2.el7.x86_64

uname -r
3.7.0-0.36.el7.x86_64

Comment 5 Marian Csontos 2013-04-18 17:44:19 UTC
There is a problem with systemd dependencies at boot: iscsi is started before network.

So I tried restarting iscsid later after boot but session is still not restored.

`iscsiadm -m node -l` works for me. Adding the line to rc.local.

Comment 6 Peter Rajnoha 2013-04-19 06:53:54 UTC
There's also a note in the /etc/init.d/iscsi init script:

# Note we should have $network in Required-Start/Stop but we don't because if
# we would require network chkconfig will put us directly after NetworkManager
# when using NM, which will make our see if the network is up test succeed
# while NM is actually still configuring the network. By not requiring network
# chkconfig will use the chkconfig header to determine our start prio, starting
# us after the old network service, but before NM (netfs does this the same).

(adding Required-Start: $network iff using network.service instead of NetworkManager.service should solve the issue)

Comment 7 michal novacek 2013-05-02 14:58:32 UTC
*** Bug 958864 has been marked as a duplicate of this bug. ***

Comment 8 michal novacek 2013-05-02 15:02:19 UTC
Is there any plan on how to solve this permanently with for example systemctl.service with proper dependencies?

Comment 10 Chris Leech 2013-06-20 20:20:17 UTC
This should be fixed with iscsi-initiator-utils-6.2.0.873-7, which is in sync with f19 and has proper systemd unit files.

Comment 11 Bruno Goncalves 2013-06-21 11:36:20 UTC
The problem continues on RHEL7.

rpm -q iscsi-initiator-utils
iscsi-initiator-utils-6.2.0.873-7.el7.x86_64

uname -r 
3.10.0-0.rc4.59.el7.x86_64

iscsiadm -m discovery
na3170b.lab.bos.redhat.com:3260 via sendtargets

iscsiadm -m session
iscsiadm: No active sessions.

From /var/log/messages:

Jun 21 11:28:17 ibm-x3500m4-01 kernel: [   16.429909] Loading iSCSI transport class v2.0-870.
Jun 21 11:28:17 ibm-x3500m4-01 dbus[654]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Jun 21 11:28:17 ibm-x3500m4-01 systemd[1]: Started Open-iSCSI.
Jun 21 11:28:17 ibm-x3500m4-01 iscsiadm[1118]: iscsiadm: Could not login to [iface: default, target: iqn.1992-08.com.netapp:sn.151753773, portal: 10.16.41.222,3260].
Jun 21 11:28:17 ibm-x3500m4-01 iscsiadm[1118]: iscsiadm: initiator reported error (12 - iSCSI driver not found. Please make sure it is loaded, and retry the operation)
Jun 21 11:28:17 ibm-x3500m4-01 iscsiadm[1118]: iscsiadm: Could not login to [iface: default, target: iqn.1992-08.com.netapp:sn.151753773, portal: 10.16.43.127,3260].
Jun 21 11:28:17 ibm-x3500m4-01 iscsiadm[1118]: iscsiadm: initiator reported error (12 - iSCSI driver not found. Please make sure it is loaded, and retry the operation)
Jun 21 11:28:17 ibm-x3500m4-01 iscsiadm[1118]: iscsiadm: Could not log into all portals
Jun 21 11:28:17 ibm-x3500m4-01 iscsiadm[1118]: Logging in to [iface: default, target: iqn.1992-08.com.netapp:sn.151753773, portal: 10.16.41.222,3260] (multiple)
Jun 21 11:28:17 ibm-x3500m4-01 iscsiadm[1118]: Logging in to [iface: default, target: iqn.1992-08.com.netapp:sn.151753773, portal: 10.16.43.127,3260] (multiple)
Jun 21 11:28:17 ibm-x3500m4-01 systemd[1]: iscsi.service: main process exited, code=exited, status=12/n/a
Jun 21 11:28:17 ibm-x3500m4-01 systemd[1]: Failed to start Login and scanning of iSCSI devices.
Jun 21 11:28:17 ibm-x3500m4-01 systemd[1]: Unit iscsi.service entered failed state.

Comment 12 Bruno Goncalves 2013-06-21 11:53:33 UTC
Okay seems the culprit now is selinux.

Making it permissive the sessions start after reboot.

Jun 21 11:28:18 ibm-x3500m4-01 avahi-daemon[638]: Registering new address record for fe80::e61f:13ff:fee0:1bf8 on em1.*.
Jun 21 11:28:18 ibm-x3500m4-01 avahi-daemon[638]: Registering new address record for fe80::e61f:13ff:fee0:1bf9 on em2.*.
Jun 21 11:28:18 ibm-x3500m4-01 setroubleshoot: SELinux is preventing /usr/sbin/iscsid from getattr access on the directory /etc/modprobe.d. For complete SELinux messages. run sealert -l 968e2e66-9b85-4e6f-bf17-1d4eb6b0cba7
Jun 21 11:28:18 ibm-x3500m4-01 setroubleshoot: SELinux is preventing /usr/sbin/iscsid from search access on the directory modules. For complete SELinux messages. run sealert -l ff4fcc47-5106-4ef0-82e6-a2041654710c
Jun 21 11:28:18 ibm-x3500m4-01 setroubleshoot: SELinux is preventing /usr/sbin/iscsid from search access on the directory modules. For complete SELinux messages. run sealert -l ff4fcc47-5106-4ef0-82e6-a2041654710c
Jun 21 11:28:18 ibm-x3500m4-01 avahi-daemon[638]: Registering new address record for fe80::e61f:13ff:fee0:1bfa on em3.*.
Jun 21 11:28:18 ibm-x3500m4-01 iscsid: iSCSI daemon with pid=1144 started!
Jun 21 11:28:18 ibm-x3500m4-01 iscsid: Could not insert module tcp. Kmod error -38
Jun 21 11:28:18 ibm-x3500m4-01 iscsid: Could not insert module tcp. Kmod error -38
Jun 21 11:28:18 ibm-x3500m4-01 setroubleshoot: SELinux is preventing /usr/sbin/iscsid from search access on the directory modules. For complete SELinux messages. run sealert -l ff4fcc47-5106-4ef0-82e6-a2041654710c
Jun 21 11:28:18 ibm-x3500m4-01 setroubleshoot: SELinux is preventing /usr/sbin/iscsid from getattr access on the directory /etc/modprobe.d. For complete SELinux messages. run sealert -l 968e2e66-9b85-4e6f-bf17-1d4eb6b0cba7
Jun 21 11:28:18 ibm-x3500m4-01 setroubleshoot: SELinux is preventing /usr/sbin/iscsid from search access on the directory modules. For complete SELinux messages. run sealert -l ff4fcc47-5106-4ef0-82e6-a2041654710c
Jun 21 11:28:18 ibm-x3500m4-01 setroubleshoot: SELinux is preventing /usr/sbin/iscsid from search access on the directory modules. For complete SELinux messages. run sealert -l ff4fcc47-5106-4ef0-82e6-a2041654710c
Jun 21 11:28:18 ibm-x3500m4-01 setroubleshoot: SELinux is preventing /usr/sbin/iscsid from search access on the directory modules. For complete SELinux messages. run sealert -l ff4fcc47-5106-4ef0-82e6-a2041654710c
Jun 21 11:28:19 ibm-x3500m4-01 avahi-daemon[638]: Registering new address record for fec0:0:a10:4000:e61f:13ff:fee0:1bf8 on em1.*.

Comment 13 Chris Leech 2013-06-21 14:34:09 UTC
(In reply to Bruno Goncalves from comment #12)
> Okay seems the culprit now is selinux.

What is the version of selinux-policy installed?
That should be fixed as of 3.12.1-51.

Comment 14 Bruno Goncalves 2013-06-21 15:22:51 UTC
Thank you, I was using selinux-policy-3.12.1-48.el7

With selinux-policy-3.12.1-52.el7 it seems to work.

Comment 15 Bruno Goncalves 2013-07-09 13:17:44 UTC
It has been fixed on

iscsi-initiator-utils-6.2.0.873-7.el7.x86_64

selinux-policy-3.12.1-59.el7.noarch

Comment 16 Ludek Smid 2014-06-13 10:52:23 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

Comment 18 Michael Watters 2018-08-07 18:07:57 UTC
I'm still seeing this issue on RHEL (CentOS) 7.5.  The system has selinux-policy-3.13.1-192.el7_5.4.noarch and iscsi-initiator-utils-6.2.0.874-7.el7.x86_64 installed. 

After reboot only one iscsi target is logged in to despite node.startup being set to automatic for all nodes.

[root@ovirt-node-production1 iscsi]# grep -r node.startup *
nodes/iqn.1984-05.com.dell:powervault.md3800i.600a09800060188f0000000054af52db/192.168.111.5,3260,1/default:node.startup = automatic
nodes/iqn.1984-05.com.dell:powervault.md3800i.600a09800060188f0000000054af52db/192.168.112.5,3260,1/default:node.startup = automatic
nodes/iqn.1984-05.com.dell:powervault.md3800i.600a098000601b4700000000549b893a/192.168.111.4,3260,1/default:node.startup = automatic
nodes/iqn.1984-05.com.dell:powervault.md3800i.600a098000601b4700000000549b893a/192.168.112.4,3260,1/default:node.startup = automatic
nodes/iqn.1994-12.com.promise.f5.3.65.55.1.0.0.20/10.201.64.101,3260,1/default:node.startup = automatic
nodes/iqn.1994-12.com.promise.f5.3.65.55.1.0.0.20/10.201.64.102,3260,1/default:node.startup = automatic


Before rebooting all targets are logged in.

[root@ovirt-node-production1 iscsi]# iscsiadm  -m session
tcp: [1] 192.168.111.5:3260,1 iqn.1984-05.com.dell:powervault.md3800i.600a09800060188f0000000054af52db (non-flash)
tcp: [2] 192.168.111.4:3260,1 iqn.1984-05.com.dell:powervault.md3800i.600a098000601b4700000000549b893a (non-flash)
tcp: [3] 192.168.112.4:3260,1 iqn.1984-05.com.dell:powervault.md3800i.600a098000601b4700000000549b893a (non-flash)
tcp: [4] 10.201.64.101:3260,1 iqn.1994-12.com.promise.f5.3.65.55.1.0.0.20 (non-flash)
tcp: [5] 10.201.64.102:3260,1 iqn.1994-12.com.promise.f5.3.65.55.1.0.0.20 (non-flash)
tcp: [6] 192.168.112.5:3260,1 iqn.1984-05.com.dell:powervault.md3800i.600a09800060188f0000000054af52db (non-flash)


After reboot only one target is active.

username@workstation:~$ ssh root@ovirt-node-production1
Last login: Tue Aug  7 13:37:07 2018 from 10.209.44.227
[root@ovirt-node-production1 ~]# iscsiadm  -m session
tcp: [1] 192.168.111.5:3260,1 iqn.1984-05.com.dell:powervault.md3800i.600a09800060188f0000000054af52db (non-flash)
tcp: [2] 192.168.112.5:3260,1 iqn.1984-05.com.dell:powervault.md3800i.600a09800060188f0000000054af52db (non-flash)

I can provide logs as needed.

Comment 19 Sudha Sundaram 2020-02-07 18:48:27 UTC
I am seeing this problem on Red Hat Enterprise Linux Server release 7.6 (Maipo)
Kernel Version: 3.10.0-957.12.2.el7.x86_64
running on VMWare

Was logged into target before a reboot. After reboot, see the following messages:

Feb 06 17:51:25 MD161-3033-04 iscsiadm[23980]: iscsiadm: No matching sessions found
Feb 06 17:51:25 MD161-3033-04 iscsid[21592]: iscsid shutting down.

The very first time after a reboot does not work.
As a workaround,  Once i do "iscsiadm --mode node --targetname iqn.1992-08.com.netapp:sn.26fa40d9362a11ea8c28005056b3aea6:vs.5 --login" it starts working thereafter.

Comment 20 M.T 2020-08-04 09:01:48 UTC
I am seeing this problem on Red Hat Enterprise Linux Server release 7.8
kernel version : 3.10.0-1127.18.2.el7.x86_64
I need to issue the iscsiadm --mode node -targetname --login every time i reboot the system

Comment 21 Bhavuk Taneja 2020-09-08 02:27:37 UTC
I believe I came across this issue on this node:


Booted kernel:  3.10.0-1062.el7.x86_64

$ grep selinux-policy sos_commands/yum/yum_list_installed 
selinux-policy.noarch                 3.13.1-252.el7.1          @os-7.7.0       
selinux-policy-devel.noarch           3.13.1-252.el7.1          @os-7.7.0       
selinux-policy-targeted.noarch        3.13.1-252.el7.1          @os-7.7.0       

$ grep iscsi-initiator-utils sos_commands/yum/yum_list_installed 
iscsi-initiator-utils.x86_64          6.2.0.874-11.el7          @os-7.7.0       
iscsi-initiator-utils-iscsiuio.x86_64 6.2.0.874-11.el7          @os-7.7.0    

---------

Its cluster node is not showing this issue, and its running on different version of selinux-policy:

Booted kernel:  3.10.0-1062.el7.x86_64

$ grep selinux-policy sos_commands/yum/yum_list_installed 
selinux-policy.noarch                 3.13.1-266.el7            @os-7.7.3       
selinux-policy-devel.noarch           3.13.1-266.el7            @os-7.7.3       
selinux-policy-targeted.noarch        3.13.1-266.el7            @os-7.7.3       

$ grep iscsi-initiator-utils sos_commands/yum/yum_list_installed 
iscsi-initiator-utils.x86_64          6.2.0.874-17.el7          @os-7.7.3       
iscsi-initiator-utils-iscsiuio.x86_64 6.2.0.874-17.el7          @os-7.7.3

---------

Have not tried to update "selinux-policy" yet and reboot the server. Will share the results as the case progresses.


Note You need to log in before you can comment on or make changes to this bug.