Environment
Novell Open Enterprise Server (Linux based)
Novell SUSE Linux Enterprise Server 10
Novell SUSE Linux Enterprise Server 9
iSCSI attached storage
Situation
Error: "iscsid[3894]: discovery session to :3260 failed to recv a PDU response,
reconnecting"
This is repeatedly seen in /var/log/messages
This is repeatedly seen in /var/log/messages
Resolution
This is caused by the iSCSI discovery process. It is possible to
change that behavior by adding 'continous=no' before the
DiscoveryAddress in /etc/iscsi.conf.
Example:
continous=no
DiscoveryAddress=aaa.bbb.ccc.ddd
Then reboot the server.
Example:
continous=no
DiscoveryAddress=aaa.bbb.ccc.ddd
Then reboot the server.
Additional Information
The man page for iscsi.conf states the following for'continuous=yes|no' :
Specify whether discovery session should be kept alive or not after doing the discovery. Valid options are:
yes iSCSI initiator waits for IdleTimeout(60 seconds, default) to get a NOP-IN from target. If initiator gets a NOP-IN from tar get during IdleTimeout then initiator replies with NOP-OUT. But if initiator does not get a NOP-IN from target during Idle ttimeout then it sends NOP-OUT and expects NOP-IN response from target within PingTimeout(5 seconds, default). If target does not respond within PingTimeout then initiator assumes the connection has been inadvertently broken, drops the current discovery session and attempts to establish a new discovery session.
no iSCSI initiator closes the connection and will not attempt to establish a new one.
Specify whether discovery session should be kept alive or not after doing the discovery. Valid options are:
yes iSCSI initiator waits for IdleTimeout(60 seconds, default) to get a NOP-IN from target. If initiator gets a NOP-IN from tar get during IdleTimeout then initiator replies with NOP-OUT. But if initiator does not get a NOP-IN from target during Idle ttimeout then it sends NOP-OUT and expects NOP-IN response from target within PingTimeout(5 seconds, default). If target does not respond within PingTimeout then initiator assumes the connection has been inadvertently broken, drops the current discovery session and attempts to establish a new discovery session.
no iSCSI initiator closes the connection and will not attempt to establish a new one.