[Pkg-iscsi-maintainers] Bug#632275: iscsid: configured replacement_timeout is ignored

[Ritesh Raj Sarraf]

On 07/01/2011 11:22 AM, Jim Paris wrote:
> I have root on iscsi, so the connection already exists by the time
> iscsid starts.  Regardless of the value of
> node.session.timeo.replacement_timeout in my /etc/iscsi/iscsid.conf,
> iscsid prints:
>
>   iscsid: Cannot set replacement_timeout to zero. Setting 120 seconds
>
> and I see:
>
>   # cat /sys/class/iscsi_session/session1/recovery_tmo 
>   120
>

This is intentional. Why are you setting it to 0?

The default is set to 120 seconds so that consumers of iSCSI that do not
use an upper stack like multipath still have a 2 minute window before
SCSI gives up.

If you want quick results, use a sane value like 5 seconds. That's what
I recommend to my users. 0 just does not make sense.

> If I change it manually, and restart iscsid, it still gets reset:
>
>   # echo 31536000 > /sys/class/iscsi_session/session1/recovery_tmo
>   # cat /sys/class/iscsi_session/session1/recovery_tmo 
>   31536000
>   # killall iscsid
>   # iscsid
>   # cat /sys/class/iscsi_session/session1/recovery_tmo 
>   120
>
Which is correct because the iscsi node database will have set the
default value (120 secs) when doing the discovery. If you want that
changed, change it to 5 in iscsid.conf and do a rediscovery.

> Which makes things very unhappy if the network ever gets disconnected
> for a few minutes.
>
If you are using SAN, you better have a good network. But that can't be
guaranteed. That is why we have Device Mapper Multipath. With
dm-multipath (and its queue_if_no_path feature), you can tackle this
scenario very easily.

> My guess is that iscsid is pulling the connection parameters from /sys
> and leaving replacement_timeout as zero in its own data structures,
> whereas it should really be filling things in with the default values
> specified in iscsid.conf.
>
> I'll attach a (slightly sanitized) log of 
>   
>   iscsid -f -d 8 
No. like I mentioned, it takes those values from the node database.


I don't see this as a bug at all. But I'd want you to close it if you
have no questions further.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-iscsi-maintainers/attachments/20110701/e09809b3/attachment.pgp>